Tests the two new detection methods for the underscore prefix
against what is detected in the binary. Contrary to the in-the-wild
failures, we can trust the binary here as we do not get any additional
flags that influence the binary contents in this test environment.
Adds a new debug() function that can be used in the meson.build to
log messages to the meson-log.txt that will not be printed to stdout
when configuring the project.
Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
If you rely on PKG_CONFIG_PATH to make anything work (like nixos) then
these tests cannot pass without the system values appended to the
override values.
Perhaps when this test case was originally created, project tests could
not use a matrix of options? This is certainly possible today, so don't
write special unittest handling for this instead.
This adds proper visibility into what gets run and what doesn't. Now we
know which python executables got tested and which got skipped.
The regex in question causes Python's regex parser to freeze
indefinitely in certain Python versions. That might be due
to a bug or because the re does infinite backtracking and it just
happened to work on earlier implementations.
This is treated by the test harness as though unset, i.e. we do normal
skipping and don't assume we are running in Meson's own project CI.
However, it has one distinction which is that it isn't an error to set
$CI without setting $MESON_CI_JOBNAME, if it is in fact set but to the
ignored value.
This lets automated workflows such as Linux distro testing, particularly
alpine linux, set $CI or have it set for them by default, without
messing things up.
Also it has the advantage of $CI actually enabling useful benefits! We
will still assume that this thirdparty environment wants to force
verbose logging (printing testlogs, running ninja/samu with -v) and
colorize the console.
The $CI environment variable may be generally set by Github or Gitlab
actions, and is not a reliable indicator of whether we are running "CI".
It could also, for an absolutely random example that didn't *just
happen*, be Alpine Linux's attempt to enable the Meson testsuite in
their packaging, which... uses Gitlab CI.
In this case, we do want to perform normal skipping on not-found
requirements. Instead of checking for $CI, check for $MESON_CI_JOBNAME
as we already use that in all of our own CI jobs for various reasons.
This makes it easier for linux distros to package Meson without
accumulating hacks like "run the testsuite using `env -u CI`".
This bring us in line with Autotools and CMake and it is useful
for platforms like Nix, which install projects
into multiple independent prefixes.
As a consequence, `get_option` might return absolute paths for some
directory options, if a directory outside of prefix is passed.
This is technically a backwards incompatible change but its effect
should be minimal, thanks to widespread use of `join_paths`/`/` operator
and pkg-config generator module. It should only cause an issue when
a path were constructed by concatenating the value of directory path option.
Also remove a comment about commonpath since we do not use that since
<00f5dadd5b>.
Fixes: https://github.com/mesonbuild/meson/issues/2561
unittests/rewritetests.py:19: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
from distutils.dir_util import copy_tree
For example:
```
meson builddir \
--native-file vs2019-paths.txt \
--native-file vs2019-win-x64.txt \
--cross-file vs2019-paths.txt \
--cross-file vs2019-win-arm64.txt
```
This was causing the error:
> ERROR: Multiple producers for Ninja target "/path/to/vs2019-paths.txt". Please rename your targets.
Fix it by using a set() when generating the list of regen files, and
add a test for it too.
This removes the ability to use ConfigurationData as a dict, but
restricting the inputs to `str | int | bool`. This may be a little too
soon for this, and we may want to wait on that part, it's only bee 8
months since we started warning about this.
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
The tests and the unittests both unconditionally call setup_vsenv()
because all tests are run using the backend commands directly: ninja,
msbuild, etc.
There's no way to undo this vs env setup, so the only way to test that
--vsenv works is by:
1. Removing all paths in PATH that provide ninja
2. Changing setup_vsenv(force=True) to forcibly set-up a new vsenv
when MESON_FORCE_VSENV_FOR_UNITTEST is set
3. Mock-patching build_command, test_command, install_command to use
`meson` instead of `ninja`
4. Asserting that 'Activating VS' is in the output for all commands
5. Ensure that compilation works because ninja is picked up from the
vs env.
I manually checked that this test actually does fail when the previous
commit is reverted.
pkgconf has a bug on MSYS2 due to which prefixes with spaces are not
handled correctly if the library has a Requires: on another library
and both have prefixes with spaces in them.
See: https://github.com/pkgconf/pkgconf/issues/238
So move the unit test to libanswer.pc instead of libfoo.pc till that
is fixed.
If a pkg-config dependency has multiple libraries in it, which is the
most common case when it has a Requires: directive, or when it has
multiple -l args in Libs: (rare), then we don't add -Wl,-rpath
directives to it when linking.
The existing test wasn't catching it because it was linking to
a pkgconfig file with a single library in it. Update the test to
demonstrate this.
This function was originally added for shared libraries in the source
directory, which explains the name:
https://github.com/mesonbuild/meson/pull/2397
However, since now it is also used for linking to *all* non-system
shared libraries that we link to with absolute paths:
https://github.com/mesonbuild/meson/pull/3092
But that PR is incomplete / wrong, because only adding RPATHs for
dependencies that specify a single library, which is simply
inconsistent. Things will work for some dependencies and not work for
others, with no logical reason for it.
We should add RPATHs for *all* libraries. There are no special length
limits for RPATHs that I can find.
For ELF, DT_RPATH or DT_RUNPATH are used, which are just stored in
a string table (DT_STRTAB). The maximum length is only a problem when
editing pre-existing tags.
For Mach-O, each RPATH is stored in a separate LC_RPATH entry so there
are no length issues there either.
Fixes https://github.com/mesonbuild/meson/issues/9543
Fixes https://github.com/mesonbuild/meson/issues/4372
Add ability to mutate a target's `extra_files` list through the
rewriter.
The logic is copied from sources add/rm, but changes the `extra_files`
kwarg instead of the sources positional argument.
Has additional logic to handle creating the `extra_files` list if it
doesn't exist.
If the compiler check is updated as a string in meson.build, we force
rebuild, which is a good thing since the outcome of that check changes
the configuration context and can enable or disable parts of the build.
If the compiler check came from a files() object then we didn't add a
regen rule on those files.
Fixes#1656
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes https://github.com/mesonbuild/meson/issues/9492
This ensures that there is no warnings when running meson on
test cases/common/22 object extraction.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, if you pass a `[]string`, but the argument expects
`[]number`, then you get a message like `expected list[str] but got
list`. That isn't helpful. With this patch arrays and dictionaries will
both print messages with the types provided.
John Ericson
Marvin Scholz
Jussi Pakkanen
Xavier Claessens
Dylan Baker
Eli Schwartz
Jan Tojnar
Daniel Mensinger
Paolo Bonzini
Nirbheek Chauhan
Celeste Wouters