Otherwise it always returns the value for c++98, starting with MSVC 2017
15.7 or later. Earlier versions are not affected by this mis-feature.
See: https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
This was originally applied as 0b97d58548
but later reverted because it made the CI red. Try it again, now.
Original-patch-by: Dylan Baker <dylan@pnwbakers.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
All changes were created by running
"pyupgrade --py3-only --keep-percent-format"
and committing the results. I have not touched string formatting for
now.
- use set literals
- simplify .format() parameter naming
- remove __future__
- remove default "r" mode for open()
- use OSError rather than compatibility aliases
- remove stray parentheses in function(generator) scopes
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
The pefile module is a CI dependency now, so we can use that instead
of objdump/dumpbin which greatly simplifies the test. Of course, this
module is also cross-platform so it will work if we add cross-win32 CI
at some point.
Fortran: check for undeclared variables by forcing implicit none everywhere
C/C++: check for unused parameters and return types
removed unused variables from test cases
ci: do missing return and unused arg check with Github Actions
Static libraries don't have PDB files. A PDB that would previously end
up installed alongside a static library belonged in fact to the dynamic
version of the same library built at the same time.
This was because the former minstall.Installer implementation, when
installing a file target, also blindly copied any *.pdb file it found
whose filename was matching the target. So, for example installing
foo.dll and foo.a would also install two copies of foo.pdb into both
bin/ and lib/, which doesn't seem like the right thing to do - foo.pdb
should only get installed with foo.dll.
Extend test case for issue #3575 for Windows resource files with the same
name to cover the case where duplicate outputs exist due to use of
pathnames.
Also Test using file objects as well as literal filenames
This test covers the case where the resource script references a file which
is created by a custom_target (in this case, an icon).
Put icon in a separate directory to ensure we excercise setting the include
path to the directory which contains it.
On Windows, if we are going to link with a shared module, we need the
implib.
Use case: The Xorg server builds some X protocol extensions as modules. The
implibs for these modules need to be shipped as part of the SDK, to enable
building of 3rd party extensions which reference symbols in (and hence on
Windows, need to be linked with) these modules.
When using binutils's windres, we can instruct it to invoke the preprocessor
in such a way that it writes a depfile, so that dependencies on #included
files are automatically tracked.
Not implemented for MSVC tools, so skip testing it in that case.
Expose depend_files: from the custom_target this creates.
This is the change suggested in #2815, with tests and documentation added.
Fixes#2789 (duplicate #2830)
Currently, this test only tries to load a predefined icon, so the resource
compilation and linking can be completely removed from the meson.build and
it still passes.
Change to try to load the icon contained in the resources we compile.
Add a boolean 'implib' kwarg to executable(). If true, it is permitted to
use the returned build target object in link_with:
On platforms where this makes sense (e.g. Windows), an implib is generated
for the executable and used when linking. Otherwise, it has no effect.
(Rather than checking if it is a StaticLibrary or SharedLibary, BuildTarget
subclasses gain the is_linkable_target method to test if they can appear in
link_with:)
Also install any executable implib in a similar way to a shared library
implib, i.e. placing the implib in the appropriate place
Add tests of:
- a shared_module containing a reference to a symbol which is known (at link
time) to be provided by the executable
- trying to link with non-implib executables (should fail)
- installing the implib
(This last one needs a little enhancement of the installed file checking as
this is the first install test we have which needs to work with either
MSVC-style or GCC-style implib filenames)