This is a) useless because it's only used to print which options are not
default, and b) harmful because it can result in cases where things
break, like in projects that set a standard that the chosen compiler
doesn't support, but the project (or some subset) can be built with a
different standard.
Fixes: #8360
run_target() does some variable substitutions since 0.57.0. This is a
new behavior, and undocumented, caused by sharing more code with
custom_target(). More consistency is better, so document it now.
custom_target() was doing variable substitution in the past, because it
shared some code with generator(), but that was undocumented. Some
refactoring in 0.57.0 caused it to not replace @CURRENT_SOURCE_DIR@,
@SOURCE_DIR@, and @BUILD_DIR@ anymore. This patch adds back
@CURRENT_SOURCE_DIR@ and document it. It does not add back @SOURCE_DIR@
because it is duplicate with @SOURCE_ROOT@ that has a better name. Also
do not add back @BUILD_DIR@ which is duplicate of @PRIVATE_DIR@, and
not @BUILD_ROOT@ surprisingly, adding to the confusion.
install_subdir() with a non-existing subdir creates the directory in the
target directory. This seems like an implementation detail but is quite useful
to create new directories for e.g. configuration or plugins in the installed
locations.
git bisect says this started with 8fe8161014.
Let's add a test for it and document it to make this behavior official.
Limitation: it can only create at the install_dir location, trying to create
nested subdirectories does not work and indeed creates the wrong directory
structure. That is a bug that should be fixed separately:
install_subdir('blah',
install_dir: get_option('prefix'))
install_subdir('sub/foobar',
install_dir: get_option('prefix'))
install_subdir('foo/baz',
install_dir: get_option('prefix'))
$ tree ../_inst
../_inst
├── baz
├── blah
└── foobar
Fixes#2904
Re-implement it in backend using the same code path as for
custom_target(). This for example handle setting PATH on Windows when
command is an executable.
Following #7890, this patch introduces the ability to read the contents
of a file to the fs module.
This patch introduces the ability to read files at configure time, but
has some restrictions:
- binary files are not supported (I don't think this will prove a
problem, and if people are wanting to do something with binary
files, they should probably be shelling out to their own script).
- Only files outside the build directory allowed. This limitation
should prevent build loops.
Given that reading an arbitrary file at configure time can affect the
configuration in almost arbitrary ways, meson should force a reconfigure
when the given file changes. This is non-configurable, but this can
easily be changed with a future keyword argument.
This commit fixes the test that asserts on whether the lchmod() function
should have been detected as available by Meson. It does so by assuming
that on Linux systems not using glibc, the function will be available.
- fix comment about lchmod on Linux: musl has implemented the function
correctly since 2013, so the assumption in the test wasn't correct.
Furthermore, musl doesn't use glibc's stub mechanism.
- fix include to receive __GLIBC__ definition: including almost any
header in glibc will end up defining __GLIBC__, since most headers
include <features.h>. The <gnu/libc-version.h> header was probably
chosen because of its name, but its actual purpose is defining functions
for checking glibc version at runtime (instead of what the binary was
built with), so it isn't necessary to use it. Since it is a completely
non standard header, including it makes the test suite fail on musl due
to not finding the header.
On Windows this would fail because of missing DLL:
```
mylib = library(...)
exe = executable(..., link_with: mylib)
meson.add_install_script(exe)
```
The reason is on Windows we cannot rely on rpath to find libraries from
build directory, they are searched in $PATH. We already have all that
mechanism in place for custom_target() using ExecutableSerialisation
class, so reuse it for install/dist/postconf scripts too.
This has bonus side effect to also use exe_wrapper for those scripts.
Fixes: #8187
A sub-subproject can be configured directly from
`subprojects/foo/subprojects/bar/` in the case `bar` is in the same git
repository as `foo` and not downloaded separately into the main
project's `subprojects/`. In that case the nested subproject violation
code was wrong because it is allowed to have more than one "subprojects"
in path (was not possible before Meson 0.56.0).
Example:
- self.environment.source_dir = '/home/user/myproject'
- self.root_subdir = 'subprojects/foo/subprojects/bar'
- project_root = '/home/user/myproject/subprojects/foo/subprojects/bar'
- norm = '/home/user/myproject/subprojects/foo/subprojects/bar/file.c'
We want `norm` path to have `project_root` in its parents and not have
`project_root / 'subprojects'` in its parents. In that case we are sure
`file.c` is within `bar` subproject.
Some license identifiers are ambiguous (e.g. "GPL3"). The SPDX license
identifiers avoid this by providing standardized and unique identifiers
(e.g. "GPL-3.0-only" or "GPL-3.0-or-later" for the previous example).
Because SPDX short-form identifiers are also both human- and
machine-readable we should recommend them in the documentation.
More information (advantages, details, etc.) can be found here:
- https://spdx.dev/resources/use/#identifiers
- https://spdx.dev/ids/Fix#7905.
wraps from subprojects are now merged into the list of wraps from main
project, so they can be used to download dependencies of dependencies
instead of having to promote wraps manually. If multiple projects
provides the same wrap file, the first one to be configured wins.
This also fix usage of sub-subproject that don't have wrap files. We can
now configure B when its source tree is at
`subprojects/A/subprojects/B/`. This has the implication that we cannot
assume that subproject "foo" is at `self.subproject_dir / 'foo'` any
more.
Sometimes, distros want to configure a project so that it does not
use any bundled library. In this case, meson.build might want
to do something like this, where slirp is a combo option
with values auto/system/internal:
slirp = dependency('', required: false)
if get_option('slirp') != 'internal'
slirp = dependency('slirp',
required: get_option('slirp') == 'system')
endif
if not slirp.found()
slirp = subproject('libslirp', ...) .variable('...')
endif
and we cannot use "fallback" because the "system" value should never
look for a subproject.
This worked until 0.54.x, but in 0.55.x this breaks because of the
automatic subproject search. Note that the desired effect here is
backwards compared to the policy of doing an automatic search on
"required: true"; we only want to do the search if "required" is false!
It would be possible to look for the dependency with `required: false`
and issue the error manually, but it's ugly and it may produce an error
message that looks "different" from Meson's.
Instead, with this change it is possible to achieve this effect in an
even simpler way:
slirp = dependency('slirp',
required: get_option('slirp') != 'auto',
allow_fallback: get_option('slirp') == 'system' ? false : ['slirp', 'libslirp_dep'])
The patch also adds support for "allow_fallback: true", which is
simple and enables automatic fallback to a wrap even for non-required
dependencies.
This is required to make the various keys in the [user options] section
work the same as they do in the meson_options.txt file, where we don't
have any rules about case sensitivity.
There is some risk here. Someone may be relying on this lower by default
behavior, and this could break their machine files.
Fixes#7731
This is a test for https://github.com/mesonbuild/meson/pull/7021, to
verify that `link.exe` uses the correct architecture when targeting
ARM64. Can be extended to other cross targets later.
Split out tests (and parts of tests) which require a native compiler
from the 'common' suite to a new suite called 'native', so we can
selectively avoid running those tests when only a cross-compiler is
available.
Also move test '211 cmake module' to 'cmake' suite, since it appears
that the way we use cmake requires a native compiler.
This removes the check for "mingw" for platform.system(). The only case I know
where "mingw" is return is if using a msys Python under a msys2 mingw environment.
This combination is not really supported by meson and will result in weird errors,
so remove the check.
The second change is checking sys.platform for cygwin instead of platform.system().
The former is document to return "cygwin", while the latter is not and just
returns uname().
While under Cygwin it uname() always starts with "cygwin" it's not hardcoded in MSYS2
and starts with the environment name. Using sys.platform is safer here.
Fixes#7552
According to the specification:
https://testanything.org/tap-specification.html#skipping-tests
The harness should report the text after # SKIP\S*\s+ as a reason for
skipping.
(it's not exactly like the TODO directive, the phrasing/presentation of
the spec could be improved).
* mtest: TestResult.SKIP is not a failure
If some but not all tests in a run were skipped, then the overall result
is given by whether there were any failures among the non-skipped tests.
Resolves: https://github.com/mesonbuild/meson/issues/7515
Signed-off-by: Simon McVittie <smcv@debian.org>
* Add test-cases for partially skipped TAP tests
issue7515.txt is the output of one of the real TAP tests in gjs, which
failed as a result of #7515. The version inline in meson.build is
a minimal reproducer.
Signed-off-by: Simon McVittie <smcv@debian.org>
Xavier Claessens
Dylan Baker
Jussi Pakkanen
Peter Hutterer
Luke Drummond
Érico Rolim
Antonin Décimo
mimi89999
Jones
Haelwenn (lanodan) Monnier
Michael Weiss
Daniel Mensinger
Sahnvour
Paolo Bonzini
Oskar Sigvardsson
Nirbheek Chauhan
Jon Turney
Christoph Reiter
Elliot
Marc-André Lureau
Michael Hirsch
Simon McVittie