Verbose, non-parallel tests generally print their output as they run, rather than
after they finish. This however is not the case if stdout of the test is parsed
as is the case for TAP and Rust tests. In this case, the output during the run
is the list of the subtests, but stderr still has to be printed after the test
finishes.
Conflicts:
mesonbuild/mtest.py [use harness.options.verbose instead of result.verbose]
Unfortunately, checking for strings without context is exceedingly prone
to false positives, while missing anything that indirectly opens a file.
Python 3.10 has a feature to warn about this though -- and it uses a
runtime check which runs at the same time that the code fails to open
files in the broken Windows locale. Set this up automatically when
running the testsuite.
Sadly, Python's builtin feature to change the warning level, e.g. by
setting EncodingWarning to error at startup, is utterly broken if you
want to limit it to only certain modules. This is tracked in order to be
more efficiently ignored at https://bugs.python.org/issue34624 and
https://github.com/python/cpython/pull/9358
It is also very trigger happy and passing stuff around via environment
variable either messes with the testsuite, or with thirdparty programs
which are implemented in python *such as lots of gnome*, or perhaps
both.
Instead, add runtime code to meson itself, to add a hidden "feature".
In the application source code, running the 'warnings' module, you can
actually get the expected behavior that $PYTHONWARNINGS doesn't have. So
check for a magic testsuite variable every time meson starts up, and if
it does, then go ahead and initialize a warnings filter that makes
EncodingWarning fatal, but *only* when triggered via Meson and not
arbitrary subprocess scripts.
We didn't consider that it has arguments following it, so the resulting
compiler command line ended up with stuff like:
-L=-rpath-link -L=-L=/path/to/directory -L=more-args
and the directory for rpath-link got eaten up as a regular -L path to
the compiler rather than being passed as -Xlinker to the linker.
Then the -rpath-link would consume the next -Xlinker argument, end up
with the wrong rpath-link (may or may not cause link errors) and then
disappear arguments we need.
As an example failure mode, if the next argument is -soname this treats
the soname text as an input file, which probably does not exist if it
was generated in a subdirectory, and also because it can never be
successfully built in the first place -- though if it did, it would link
to itself which is very wrong.
If --no-rebuild is used, the test program might not exist, spawning a
FileNotFoundError inside a long traceback rooted in subprocess.Popen
trying to run that test program. Current versions of Meson even say it's
an "unhandled python exception".
But we can do one better and actually tell the user what is wrong, why,
and what to do to fix it. And we can do so before getting waist deep in
partially running tests.
Fixes#10006
This header is required anyway. And the compile test for linking to libc
with the gettext symbol, can succeed when we try to use the literal
symbol name without includes, but fail later during project build,
because actually including libintl.h might redefine the function to match
a forked symbol. This happens when GNU libintl is installed as a
standalone library on systems that have a less fully-featured gettext
implementation.
So, by including the header in has_function, we can ensure that we test
against the default resolved header. In the event that the symbol which
is #define'd by the header is 'libintl_gettext', linking will fail against
libc even when a builtin gettext does exist, and we will fall back to the
intl dependency that provides -lintl (and which is needed to properly
use the default header).
Of course, even that probably won't work.
has_function(prefix: '...') is useless to check the difference between
builtins and external library functions. It has code to detect
"builtins" that misfires in some cases (previously seen with iconv_open).
Instead compile an open-coded test file that this intl dependency
implementation fully controls, that doesn't get up to imaginative edge
cases like trying to find `__builtin_gettext`.
It's the only way to be sure.
Fixes compiling against the intl dependency on e.g. Alpine Linux when the
libintl package is installed.
Android requires shared modules that use symbols from other shared
modules to be linked before they can be dlopen()ed in the correct
order. Not doing so leads to a missing symbol error:
https://github.com/android/ndk/issues/201
We need to always allow linking for this. Also add a soname, although
it's not confirmed that it's needed, and it doesn't really hurt if it
isn't needed.
On Windows using MSYS2 MinGW installing the package `mingw-w64-x86_64-wxmsw3.1` provides `wx-config-3.1`. I have tried building my software by making this exact change and it build correctly.
In commit b30dddd4e5, various refactorings
were done, during which a kwarg got accidentally dropped from the
function that determined part of the log message. As a result, a ':'
suddenly appeared in the log message where none should be.
Example expected output:
Checking if "-Werror=shadow with local shadowing" compiles: YES
What actually happened:
Checking if "-Werror=shadow with local shadowing" : compiles: YES
Fixes#9974
RuntimeError is way too generic when we have an explicit class for
"Meson reports to the user, something went wrong".
Moreover we now tell people that generic exceptions are "Meson bugs and
should be reported", so our failure to do the technically correct thing
and report the right kind of exception means we get haunted by demons of
confusion. Specifically, people complain to us that Meson told them
"there is a bug in Meson" when their install fails due to meson.build or
build environment issues.
This has never worked for built/found programs, only for script files.
In commit 2fabd4c7dc scripts learned an
attribute stating which subproject they came from. In commit
3990754bf5 dist scripts learned to run
even from a subproject, and relied on that attribute to know when, in
fact, they came from a subproject.
Unfortunately the original attribute was only set in one half of an
if/else, and the other half returned early with only part of the work
done.
Fixes#9964
In commit 0deab2ee9e we added the ability
to pass a declare_dependency() to any compiler method that accepts
"dependencies", but we never marked the version it is available since.
Fixes#9957
For static library crates that depend on other internal static library
crates, all link_with targets get promoted to link_whole targets. Due to
a bug, only link_with targets are considered when generating a Rust
target for the ninja backend. This made it impossible to link a Rust
static library with another internal Rust static library.
This change fixes that issue by chaining link_whole_targets with
link_targets, just like many other languages within the ninja backend.
Basically the last thing we did during target processing was to generate
shlib symlinks for e.g. libfoo.so -> libfoo.so.1.
In some cases we would dispatch to another function and return early,
though, which meant we never got far enough to generate the symlinks.
This then led to breakage when people tried to compile against libfoo.so
This surely breaks -uninstalled.pc usage, and also caused problems in
https://github.com/rust-lang/rust/pull/90260
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.
The utility function that processes this for both 'variables' and
'uninstalled_variables' accepts a kwarg for the name of the argument,
but then hardcodes 'variables' in the warning message. This is
misleading.
It's not a MesonBug which needs to be reported, and the existing error
already adequately points out the problematic file.
It is impossible to get a PermissionError for files created by meson
itself, once the build directory has been created, anyway.
This was allows up to 0.61.0 (including with the initial type
annotations), but was accidentally broken by fixes for other bugs in
0.61.1.
Fixes: #9883
In commit 06481666f4 this warning got
moved from build.py to the interpreter. Unfortunately it got added to
the wrong function... it is supposed to be part of custom_target and
even mentions this as the feature_name.
Since then, build_always became a KwargInfo and has the deprecated-since
attribute baked into it. But it didn't have the additional message which
it really should have.
Add that message at the same time we remove it from vcs_tag.
In commit 928078982c a good error message
about the directory not being a valid build directory, was replaced by a
worse message.
In commit abaa980436 the error message was
replaced by a traceback when trying to load the coredata before checking
if it was a build directory.
Revert back to using the helper function with the good error message.
Reorganize code so that we check basic things first, and do less work
before detecting errors.
Fixes#9584
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.
Otherwise we might not find a ninja that was picked up from the Visual
Studio installation.
```
$ meson setup _build
...
Activating VS 15.9.40
...
Found ninja-1.8.2 at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.EXE"
$ meson compile -C _build
Activating VS 15.9.40
...
$ meson install -C _build
Can't find ninja, can't rebuild test.
```
Fixes https://github.com/mesonbuild/meson/issues/9774
It used to support:
- a single string
- an array of anything
And as long as CustomTarget supported it too, everything worked fine.
So, a `files('foo')` worked but a `files('foo')[0]` did not, which is
silly... and it's not exactly terrible to use files() here, the input is
literally a list of source files.
Fixes building gnome-terminal
Fixes#9827
Test updated by Nirbheek Chauhan <nirbheek@centricular.com>
The original attempted fix only allowed configuration to succeed, but
not building. It was modeled based on the gdbus-codegen documentation,
which states:
--annotate WHAT KEY VALUE WHAT KEY VALUE WHAT KEY VALUE
Add annotation (may be used several times)
which clearly indicates that gdbus-codegen accepts an --annotate flag
that is followed by a multiple of 3 values, despite this not actually
working.
The manpage actually contradicts the --help text:
--annotate ELEMENT KEY VALUE
Used to inject D-Bus annotations into the given XML files. []
... and gives examples that use multiple --annotate flags each with 3
arguments.
To better understand what meson is supposed to do here, we should look
at ef52e60936, which ported to
typed_kwargs. There is actually a big chunk of code to handle
annotations that got completely dropped, leading with a comment (that
did not get dropped): "they are a list of lists of strings..."
Reimplement this logic inside a validator/converter for the annotations
kwarg container:
- do not listify, we don't accept `annotations: ''` and listify is
supposed to be for when either x or list[x] is valid
- go back to checking for a list of exactly 3 values
- allow a list of the aforementioned, in the traditionally expected
form:
[
['foo1', 'foo2', 'foo3'],
['bar1', 'bar2', 'bar3'],
]
- pass one --annotate flag per 3-value-list
And add some better error reporting for the cause of errors when
processing lists of lists.
Visual Studio Express does not come with the
'Microsoft.VisualStudio.Component.VC.Tools.x86.x64' workload.
This adds a check for the 'Microsoft.VisualStudio.Workload.WDExpress'
workload. Non-express versions take precedence over express versions
when activating.
When a custom_target() uses an env, meson uses a wrapper
script to run the executable. This breaks the console: kwarg
because the wrapper script buffers the output. Fix it by setting
the verbose flag which will not buffer output.
As soon as we check for args[1] we declare it is of type FileOrString,
and the additional ones specified in the `sources` kwarg explicitly
allow this. It makes no sense to not accept it as the posarg too.
Fixes building tracker-miners.
Fixes gtk3 build, which uses typesfile.
All these arguments are processed by a function that explicitly handles
both str and File, and converts them to absolute paths. They clearly
need to handle File objects.
Per the gdbus-codegen documentation, this "may be used several times",
and it is:
- a valid use case
- used that way in the wild
Fixes building at least geoclue2, gdm.
Regression in commit 566c2c9a9c.
The interpreter details are a bit of black magic. Functions expect
tuples, but they receive lists and then the type-checking decorators
convert those to tuples.
So, directly manhandling a self._interpreter.func_*() but passing it the
tuple it nominally expected, actually explodes in your face by way of
failing an assert, then dumping 'ERROR: Unhandled python exception'.
Fixes use of gnome.gtkdoc(..., check: true), for example when building
glib.
This is basically a rewrite of the gnome.yelp target to remove the
ad-hoc script, which generates multiple issues, including meson
not knowing which files were installed.
Closes#7653Closes#9539Closes#6916Closes#2775Closes#7034Closes#1052
Related #9105
Related #1601
Nirbheek Chauhan
Paolo Bonzini
Eli Schwartz
apoorv569
Alyssa Ross
Tobias Pankrath
Ole André Vadla Ravnås
Zach Reizner
Dylan Baker
Bilal Elmoussaoui
Gatgat
DFOVIT
Declan Qian
Michal Vasilek
Jussi Pakkanen
Pablo Correa Gómez