This new keyword argument makes it possible to run specific
test setups only on a subset of the tests. For example, to
mark some tests as slow and avoid running them by default:
add_test_setup('quick', exclude_suites: ['slow'], is_default: true)
add_test_setup('slow')
It will then be possible to run the slow tests with either
`meson test --setup slow` or `meson test --suite slow`.
[why]
If we build and test a library we need to make sure that we find the
currently build library object first, before an older system installed
one.
This can be broken if the library in question is installed in a custom
path, and another library we depend on also is installed there.
[how]
Just move the rpath to the current build artifacts to the front.
Solves #8030.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
many compilers allowed "nodiscard" C++17 feature with pre-c++17 flags.
The C++17 filesystem typically actually does require -std=c++17.
This makes this unit test more representative of C++17 flag support.
Right now sub-sub projects are not correctly registered, because we
don't have a way to pass up past the first level of subproject. This
patch changes that by making the build_Def_files as defined in the
Interpreter initializer accurate for translated dependencies, ie, cmake
dependencies won't define a dependency on a non-existent meson.build.
This means that it can always add the subi.build_def_files because they
are always accurate.
Currently if you change the `choices` field in the meson_options.txt
file, no update will be done until `meson setup --wipe` is called. Now
if the choices change then the options will be properly merged.
If the currently select value is still valid it is guaranteed to be
kept, if it is now invalid the new default value will be used and a
warning will be printed.
Fixes#7386
`pathlib.Path.glob()` also returns directories that match source
filenames (i.e. a directory named `test.h/`), but `clang-format` and
`clang-tidy` fail when handed a directory. We manually skip calling
`clang-format` and `clang-tidy` on those directories.
If the meson.build doesn't use a native compiler, the native compiler
options (e.g. 'c_args') shouldn't be present in the output of 'meson
introspect --buildoptions'.
Something like {a: foo} currently stymies the IntrospectionInterpreter and
breaks introspection of the source directory. The fix is just to walk the keys
and return a dummy dictionary.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the ids of any target that needs to be rebuilt before running the
tests as computed by the backend, to the introspection data for tests and benchmarks.
This also includes anything that appears on the test's command line.
Without this information, IDEs must update the entire build before running
any test. They can now instead selectively build the test executable
itself and anything that is needed to run it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
when that statement gets evaluated, the interpreter remembers the
version target and if it was part of the evaluation of a `if` condition
then the target meson version is temporally overriden within that
if-block.
Fixes: #7590
- Exceptions raised during subproject setup were ignored.
- Allow c_stdlib in native file, was already half supported.
- Eliminate usage of subproject variable name by overriding
'<lang>_stdlib' dependency name.
This allows adding a `[project options]` section to a cross or native file
that contains the options defined for a project in it's meson_option.txt
file.
Since mesonbuild/environment.py doesn't recognize Studio compilers,
force use of gcc on Solaris for now.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Otherwise a wrapper script which takes an executable as an argument will
mistakenly run when that executable is cross compiled. This does not
wrap said executable in an exe_wrapper, just skip it.
Fixes#5982
If an executable is passed as an argument to a script in the build
directory that it resides in then it will not execute (on *nix) due to a
lack of ./. Ie, `foo` must be called as `./foo`. If it is called from a
different directory it will work. Ie `../foo` or `bar/foo`.
Fixes#5984
The implementation of this function has changed enough that the name
doesn't really reflect what it actually does. It basically returns true
unless you're cross compiling, need and exe_wrapper, and don't have one.
The original function remains but is marked as deprecated.
This makes one small change the meson source language, which is that it
defines that can_run_host_binaries will return true in build == host
compilation, which was the behavior that already existed. Previously
this was undefined in build == host compilation.
Previously if a user tried to pass a command line build
option that contained a '%' character the command line
parser assumed that there was string interpolation to be
done. As there is no sense in such a scenario no code
provides any input for the interpolation. This then leads to
a failure.
In this commit we specifically override the defaults in
ConfigParser and set interpolation to None, which disables
command line build option interpolation.
Fixes#6157
When a static library link_whole to a bunch of other static libraries,
we have to extract all their objects recursively. But that could
introduce duplicated objects. ar is dumb enough to allow this without
error, but once the resulting static library is linked into an
executable or shared library, the linker will complain about duplicated
symbols.
A build with a cross file should always be identified as a cross build, even if
the host and build machine are identical. This was the case in 0.50, regressed
in 0.51, and is fixed again in 0.52, so add a test case to ensure it doesn't
regress again.
* Do not strip static archives
Stripping static archives without more fine-grained options (e.g. `-g`)
leads to failures such as
ld: libfoo.a: error adding symbols: archive has no index; run ranlib to add one
because GNU strip removes *every* symbol in a static archive by default.
Given that static archives are not final build artifacts (unlike
executables and shared libraries), stripping them gains little and only
causes more edge case failures.
* Gentoo's portage only strips debug information:
86f211e3a5/bin/estrip (L322)
* Fedora also only strips debug information:
e9c13c6565/scripts/brp-strip-static-archive (L18)
* Debian also only does some very light stripping:
72ed1d3261/dh_strip (L374)Fixes#4138
* Add test case for static archive stripping
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
For consistency, it can be useful to have an explicit empty test suite list
for a test:
test('test-name', binary, suite: [])
This currently passes meson but fails when running meson tests:
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/mesonbuild/mesonmain.py", line 122, in run
return options.run_func(options)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 1005, in run
return th.doit()
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 756, in doit
self.run_tests(tests)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 896, in run_tests
visible_name = self.get_pretty_suite(test)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 875, in get_pretty_suite
rv = TestHarness.split_suite_string(test.suite[0])[0]
IndexError: list index out of range
Fix it by simply checking for the test suite to be a valid list we can pass on
Fixes#5340
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Warn when someone tries to use append() or prepend() on an env var
which already has an operation set on it. People seem to think that
multiple append/prepend operations stack, but they don't.
Closes https://github.com/mesonbuild/meson/issues/5087
This creates a new command line option to store pkg_config_path into,
and store the environment variable into that option. Currently this
works like the environment variable, for both cross and native targets.
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
* Fixed spelling
* Merged the Buildoptions and Projectinfo interpreter
* Moved detect_compilers to Environment
* Added removed test case
* Split detect_compilers and moved even more code into Environment
* Moved set_default_options to coredata
* Small code simplification in mintro.run
* Move cmd_line_options back to `environment`
We don't actually wish to persist something this unstructured, so we
shouldn't make it a field on `coredata`. It would also be data
denormalization since the information we already store in coredata
depends on the CLI args.
Since `_process_libs` appends the lib's dependencies this list already,
the final return value of `_process_libs` will end up after its
dependencies, which is the wrong way around. (The lib must come first,
then its dependencies)
The easiest solution is to simply pre-pend the return value of
`_process_libs` rather than appending it, so that its dependencies come
after the library itself.
Closes#4091.
this adds support for generating pkgconfig files for c#.
The difference to c and cpp is that the -I flag is not known to the c#
compiler, but rather the -r flag which is used to link a .dll file into
the compiled library.
However this opens the question of validating which pkgconfig files can
be generated (depending on the language).
This implements 4409.
When trying to cross-compile mesa on an aarch64 system, I noticed some
strange behavior. Meson would only ever find the wayland-scanner binary
in my host machine's sysroot (/mnt/amethyst):
Native dependency wayland-scanner found: YES 1.16.0
Program /mnt/amethyst/usr/bin/wayland-scanner found: YES (/mnt/amethyst/usr/bin/wayland-scanner)
It should be finding /usr/bin/wayland-scanner instead, since the
wayland-scanner dependency is created as native. On closer inspection,
it turned out that meson was ignoring the native argument passed to
dependency(), and wuld always use the pkgconfig binary specified in my
toolchain instead of the native one (/usr/bin/pkg-config):
Native dependency wayland-scanner found: YES 1.16.0
Called `/home/lyudess/Projects/panfrost/scripts/amethyst-pkg-config
--variable=wayland_scanner wayland-scanner` -> 0
Turns out that if we create a dependency() object with native:false, we
end up caching the pkg-config path for the host machine in
PkgConfigDependency.class_pkgbin, instead of the build machine's
pkg-config path. This results causing in all pkg-config invocations for
dependency() objects to use the host machine's pkg-config binary,
regardless of whether or not 'native: true' was specified when the
dependency() object was instantiated.
So, fix this by never setting PkgConfigDependency.class_pkgbin for cross
dependency() objects. Also, add some test cases for this. Since
triggering this bug can be avoided by creating a dependency() objects
with native:true before creating any with native:false, we make sure
that our test has two modes: one where it starts with a native
dependency first, and another where it starts with a cross dependency
first.
As a final note here: We currently skip this test on windows, because
windows doesn't support directly executing python scripts as
executables: something that we need in order to point pkgconfig to a
wrapper script that sets the PKG_CONFIG_LIBDIR env appropriately before
calling pkg-config.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
meson.add_dist_script, introduced in #3906, did not accept any arguments
other than script name. Since all other meson.add_*_script methods
do accept args, this makes the dist script accept them as well.
Correct version_compare_condition_with_min() for the case where no minimum
version is established by the version constraint. Add a simple test.
Also fix test_feature_check_usage_subprojects by escaping regex
metacharacters.
if |condition| is '<', '<=' or '!=', the minimum version satisfying the
condition is 0, so the minimum version for a feature is never met.
if |condition| is '>=' or '==', the minimum version satisfying the condition
is the version compared with, so the minimum version for a feature must be
less than or equal to that.
if |condition| is '>', the minimum version satisfying the condition is
greater than the version compared with, so the minimum version for a feature
must be less than that
(it's this last condition that makes this function necessary, as in all
other cases we could establish a definite minimum version which we could
compare to see if it's less than or equal to the current version)
Fixed manually promoting wrap files with a full path, e.g.
`meson wrap promote subprojects/s1/subprojects/projname.wrap`,
which resulted in an error before (new test added:
`./run_unittests.py AllPlatformTests.test_subproject_promotion_wrap`).
Additionally, running promote with an invalid subproject path now fails
properly. Before, it just silently did nothing (added to test:
`./run_unittests.py AllPlatformTests.test_subproject_promotion`).
We used to immediately try to use whatever exe_wrapper was defined in
the cross file, but some people generate the cross file once and use
it for several projects, most of which do not even need an exe wrapper
to build.
Now we're a bit more resilient. We quietly fall back to using
non-exe-wrapper paths for compiler checks and skip the sanity check.
However, if some code needs the exe wrapper, f.ex., if you run a built
executable using custom_target() or run_target(), we will error out
during setup.
Tests will, of course, continue to error out when you run them if the
exe wrapper was not found. We don't want people's tests to silently
"pass" (aka skip) because of a bad CI setup.
Closes https://github.com/mesonbuild/meson/issues/3562
This commit also adds a test for the behaviour of exe_wrapper in these
cases, and refactors the unit tests a bit for it.
We now pass the current subproject to every FeatureNew and
FeatureDeprecated call. This requires a bunch of rework to:
1. Ensure that we have access to the subproject in the list of
arguments when used as a decorator (see _get_callee_args).
2. Pass the subproject to .use() when it's called manually.
3. We also can't do feature checks for new features in
meson_options.txt because that's parsed before we know the
meson_version from project()
This is accepted by all other binaries in the cross file. With this
change, we also don't check whether the specified command exists at
configure time, but that's probably a feature anyway.
Fixes https://github.com/mesonbuild/meson/issues/3737
* Add a test case for bad de-dup of -framework args
https://github.com/mesonbuild/meson/issues/3800
* pkgconfig: Don't naively de-dup all arguments
Honestly don't know what I was smoking. Of course the `Libs:` field in
a pkg-config file can have arguments other than -l and -L
Closes https://github.com/mesonbuild/meson/issues/3800
* pkgconfig module: Fix needlessly aggressive de-dup
On macOS, we set the install_name for built libraries to
@rpath/libfoo.dylib, and when linking to the library, we set the RPATH
to its path in the build directory. This allows all built binaries to
be run as-is from the build directory (uninstalled).
However, on install, we have to strip all the RPATHs because they
point to the build directory, and we change the install_name of all
built libraries to the absolute path to the library. This causes the
install name in binaries to be out of date.
We now change that install name to point to the absolute path to each
built library after installation.
Fixes https://github.com/mesonbuild/meson/issues/3038
Fixes https://github.com/mesonbuild/meson/issues/3077
With this, the default workflow on macOS matches what everyone seems
to do, including Autotools and CMake. The next step is providing a way
for build files to override the install_name that is used after
installation for use with, f.ex., private libraries when combined with
the install_rpath: kwarg on targets.
When we link to an external library either with find_library() without
any dirs:, or with dependency(), we should be able to run uninstalled
out of the box without having to set any environment variables or other
shenanigans.
This is especially important on macOS because only the system frameworks
directory is in the default runtime path, and all other frameworks and
libraries need to be found with RPATH or absolute path to the dylib.
This simplifies a lot of code, and centralize "key=value" parsing in a
single place.
Unknown command line options becomes an hard error instead of
merely printing warning message. It has been warning it would become an
hard error for a while now. This has exceptions though, any
unknown option starting with "<lang>_" or "b_" are ignored because they
depend on which languages gets added and which compiler gets selected.
Also any option for unknown subproject are ignored because they depend
on which subproject actually gets built.
Also write more command line parsing tests. "19 bad command line
options" is removed because bad cmd line option became hard error and
it's covered with new tests in "30 command line".
This will copy the file to the build directory without trying to read
it or substitute values into it.
Also do this optimization if the configuration_data() object passed to
the `configuration:` kwarg is empty, and print a warning about it.
See also: https://github.com/mesonbuild/meson/issues/1542