One thing that makes cross compiling with meson a pain is the need for
cross files. The problem is not with cross files themselves (they're
actually rather brilliant in that they allow for a much greater deal of
flexibility than autotools hardcoded paths approach) but that each user
needs to reimplement them themselves, when for most people what they
really want is a cross file that could be provided by their distro, all
they really want is the correct toolchain.
This patch is the first stop to making it easier for distros to ship
their own cross files (and for users to put their's somewhere safe so
they don't get `git clean`ed. It allows the cross files (on Linux and
*BSD) to be stored in home and system paths (~/.config/meson/cross,
/usr/share/meson/cross, and /usr/local/share/meson/cross), and to be
loaded by simply by specificying --cross-file.
With this patch meson will check the locations its always checked first,
(is cross file absolute, or is it relative to $PWD), then will check
~/.config/meson/cross, /usr/local/share/meson/cross,
/usr/share/meson/cross, (or $XDG_CONFIG_PATH and $XDG_DATA_DIRS) for the
files, raising an exception if it cannot find the specified cross file.
Fixes#2283
This exposes the already existing UserStringArrayOption class through
the meson_options.txt. The intention is to provide a way for projects to
take list/array type arguments and validate that all of the elements in
that array are valid without using complex looping constructrs.
Rather than requiring a bit of boilerplate in every meson.build, which is
only documented in a comment in mesoncore.py, use sensible defaults for
sysconfdir, localstatedir and sharedstatedir depending on the prefix.
Fixes#1637
v2:
For clarity, give get_builtin_option_default() a noneIfSuppress argument,
rather than overloading prefix '' and None with special meanings.
The old caching was a mess of spaghetti code layered over pasta code.
The new code is well-commented, is clear about what it's trying to do,
and uses a blacklist of keyword arguments instead of a whitelist while
generating identifiers for dep caching which makes it much more robust
for future changes.
The only side-effect of forgetting about a new keyword argument would
be that the dependency would not be cached unless the values of that
keyword arguments were the same in the cached and new dependency.
There are also more tests which identify scenarios that were broken
earlier.
Use an ordered dict for the compiler dictionary and sort it according
to a priority order: fortran, c, c++, etc.
This also ensures that builds are reproducible because it would be
a toss-up whether a C or a C++ compiler would be used based on the
order in which compilers.items() would return items.
Closes https://github.com/mesonbuild/meson/issues/1370
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.
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.
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.
os.path.commonpath (and our implementation of it) both always return the
path using the native operating system path separator, so we can't just
directly compare it since the prefix could be specified in '/', and
commonpath would use '\' on Windows.
Also add a unit test for this.
os.path.commonpath was added in Python 3.5, so just write our own for
now. pathlib was added in Python 3.4, so this should be ok. We need to
use that instead of doing str.split() etc because Windows path handling
has a lot of exceptions and pathlib handles all that for us.
Also adds a unit test for this.
At the same time, also fix the order in which compile arguments are
added. Detailed comments have been added concerning the priority and
order of the arguments.
Also adds a unit test and an integration test for the same.
With the exception of things like sysconfdir (/etc), every other
installation directory option must be inside the prefix.
Also move the prefix checks to coredata.py since prefix can also be set
from inside project() with default_options and via mesonconf. Earlier
you could set prefix to a relative path that way.
This also allows us to return consistent values for get_option('xxxdir')
regardless of whether relative paths are passed or absolute paths are
passed while setting options on the command-line, via mesonconf, or via
default_options in project(). Now the returned path will *always* be
relative to the prefix.
Includes a unit test for this, and a failing test.
Closes#1299
Jussi Pakkanen
Dylan Baker
William Hubbs
Xavier Claessens
Jon Turney
Nirbheek Chauhan
Nicolas Schneider
Hemmo Nieminen
Mike Sinkovsky