Special wrap modes:
nofallback: Don't download wraps for dependency() fallbacks
nodownload: Don't download wraps for all subproject() calls
Subprojects are used for two purposes:
1. To download and build dependencies by using .wrap files if they
are not provided by the system. This is usually expressed via
dependency(..., fallback: ...).
2. To download and build 'copylibs' which are meant to be used by
copying into your project. This is always done with an explicit
subproject() call.
--wrap-mode=nofallback will never do (1)
--wrap-mode=nodownload will do neither (1) nor (2)
If you are building from a release tarball, you should be able to
safely use 'nodownload' since upstream is expected to ship all
required sources with the tarball.
If you are building from a git repository, you will want to use
'nofallback' so that any 'copylib' wraps will be download as
subprojects.
Note that these options do not affect subprojects that are git
submodules since those are only usable in git repositories, and you
almost always want to download them.
This will benefit projects such as GNOME Recipes that prefer using
submodules over wraps because it's easier to maintain since git is
aware of it, and because it integrates with their existing
workflow. Without this, these projects have to manually initialize
the submodules which is completely unnecessary.
Closes https://github.com/mesonbuild/meson/issues/1449
Also use a pathlib.Path object for the checks since it does I/O only
once and is much more efficient anyway. Path objects are available
since Python 3.4, so this is fine.
Besides fixing output capture, it also fixes a strange bug in MSBuild
where if the command list is too long, it will remove random
characters from the command list before passing it to the command.
Closes https://github.com/mesonbuild/meson/issues/1417
For newer VS versions, we can simply rely on 'VisualStudioVersion' being
set in the environment.
For VS2010, we fall back to check 'VSINSTALLDIR' for the version string.
If the backend can not be auto detected, we raise an exception to make the
user choose an explicit backend.
We also print the detected backend to the meson log.
We were adding them to the CompilerArgs instance in the order in which
they are specified, which is wrong because later dependencies would
override previous ones. Add them in the reverse order instead.
Closes https://github.com/mesonbuild/meson/issues/1495
The 'Visual Studio 2017' image does not include VS2010, so we have to use
the 'Visual Studio 2015' image by default and only use the 2017 image for
msvc2017 compiler tests.
VS2017 requires the 'WindowsTargetPlatformVersion' property to be set.
We gather the version to use from the environment variable
'WindowsSDKVersion' that will be set by the VS developer command prompt.
VS2015 automatically picks up outputs from CustomBuild commands, which we
now use instead of CustomBuildStep commands, which do not get picked up
automatically.
This changes how generated files are added to the VS project.
Previously, they were all added as a single CustomBuildStep with all
generator commands, inputs and outputs merged together.
Now, each input file is added separately to the project and is given a
CustomBuild command. This adds all generator input files to the files list
in the VS gui and allows to run only some of the generator commands if
only some of the input files have changed.
Because we are using check_output, if the command fails no output will
be printed at all. So, we use subprocess.run instead.
Also, on configure failures, print the meson-log.txt instead of stdout.
Also forcibly undefine __has_include and test that the fallback include
check in cc.has_header() works.
This is important because all the latest compilers support it now
and we might have no test coverage at all by accident. GCC 5, ICC 17,
Clang 3.8, and VS2015 Update 2 already support it.
We differ from cmake in the following manner:
* We only set the major version (SOVERSION) in the dylib
* If SOVERSION is not specified, we deduce it from version (VERSION)
See installed_files.txt for a list of output dylib names.
In this test, we try to manually link against the generated library to
create an executable and then run it to verify that it works.
Also test for all possible library versioning in the versioning tests on
Windows. Even though they yield the same dll naming, we should still
test it.
Thibault Saunier
Jussi Pakkanen
Nirbheek Chauhan
Nicolas Schneider
Nicolas Schneider
Patrick Griffis
Matthias Klumpp
Tim-Philipp Müller
Haakon Sporsheim
Michal Sojka