It's a dumb check which doesn't know the difference between python
functions and string data. Work around this by changing the message
output to not include an opening parenthesis, and changing other similar
strings the same way for consistency.
All these dependencies are impossible to find on versions of Meson older
than the ones they got custom lookups in, because they don't provide
pkg-config files. So they should not / cannot be reasonably used on
older versions, and it is easy to say "yep, these should emit a
FeatureNew for the versions they got added in".
It would be too difficult and probably a layering violation to give an
interpreter handle to the inner guts of every dependency. What we can do
instead is let every dependency track:
- the Feature checks it can produce,
- the version attribute for when it was implemented
while leaving the interpreter in charge of actually emitting them.
The point of a .use() function is because we don't always have the
information we need to use a feature check, so we allow creating the
feature and then storing it for later use. When implementing location
checks, although it is optional, actually using it violated that design.
Move the location out of the init method for FeatureCheck itself. It
remains compatible with all cases of .single_use(), but fix the rest up.
When the project instals GDB helper scripts, copy them into
meson-private directory with the right tree layout and write a .gdbinit
script to load them automatically.
The documentation on how shaderc is checked in meson was quite behind.
Update it to mention that pkg-config is the default and preferred method
of checking. Also be specific about what order everything is checked in
since shaderc is confusing.
Do not traceback when trying to update a wrap that isn't a [wrap-file],
just report the problem.
Do not traceback on perfectly valid WrapDB wraps that don't have a
patch_url because they have upstream meson.build, instead try to parse
the version from the source tarball filename.
There's no reason it needs a concrete list, any iterable is fine. This
does mean that we need to explicitly check for `str | bytes` in the
listify pass, as `str` and `bytes` are both iterable.
The default behavior of installing relative to prefix may be unexpected,
and is definitely wrong in many cases.
Give users control in order to specify that yes, they actually want to
install to a venv.
This is particularly useful for projects that use meson as a build
system for a python module, where *all* files shall be installed into
the python site-packages.
For a test to be displayed to stdout without buffering, it has to be
1) in verbose mode 2) not executed in parallel with others
3) not parsed, i.e. not TAP or Rust. Include these three
conditions in a new property of stdout and use it in the
three places where it matters: when printing the initial
and final delimiters of the output, and when deciding the
console mode to use.
Suggested-by: Jussi Pakkanen <jpakkane@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently it tries to run "cmd" by default in a MSYS2 bash.
Passing "bash" doesn't work since that defaults to WSL and
one has to pass an absolute path to bash instead, and even then
one misses out on the PS1 override.
In case $SHELL is set and the contained path exists prefer it even if
we are on Windows.
To make the PS1 override work we can't use Unix paths in Python since
we might be on Windows, so move the .bashrc check into the temporary
bash script itself.
This makes "meson devenv" work the same under MSYS2 as on Linux.
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
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.
In a bunch of cases we create a series of sample libraries named "a",
"b", "c" etc.
This breaks on musl. Originally reported with muon via commit
ca5c371714
and also breaks the testsuite when packaging meson for alpine linux.
libc.so is an existing library which is linked in by default for all the
obvious reasons. You can get away with this on glibc, because that
includes a soversion of "6", but it loads the wrong library on musl.
Follow-up on commit 4274e0f42a. We want to
allow tests to be skipped freely in third-party environments, so this
should check the jobname, not whether $CI exists.
We will anyways raise an error when trying to run the project tests, if
$CI is set but no jobname is set.
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.
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.
find_program() can check that for us already, there's no need to
require GNU bash on systems that default to other POSIX shells.
Even though this is the *linuxlike* tests and a POSIX shell is
guaranteed, there is actually no need to require a shell at all. It's
*easier* to use the meson builtin functionality here.
Instead of blindly assuming when $CI is set that `ninja` is always
correct and always new enough, check for it the same way we do when $CI
is not set.
Instead of special casing when $CI is set and skipping ninja detection
in subprocess tests (by assuming it is always `ninja`), skip detection
in subprocess tests all the time, by passing this information around
across processes after the first time it is looked up.
This means that local (non-CI) tests are faster too!
Fixes running unittests in alpine linux using samu. Although ninja is a
symlink to samu, the exact output string on no-op builds is different,
which we already handle, but what we don't handle is the fact that samu
prints a third case when you invoke it as `ninja`. If $CI is exported,
then the unittests ignored $NINJA entirely.
Fixes running unittests when $CI is set, `samu` exists and `ninja` does
not exist. This is not currently the case anywhere, but may be in the
future; why not fix it now?
Given a meson.build with the contents:
```
t = '
'
```
We want to warn that this is bad. So we emitted this warning:
```
WARNING: Newline character in a string detected, use ''' (three single quotes) for multiline strings instead.
This will become a hard error in a future Meson release. t = ' 4 4
```
The line contents and the offset are printed as gibberish after a big
whitespace run. These are elsewhere often passed to ParseException,
which pretty-prints this, but newlines aren't an exception, merely a
warning, and mlog.warning doesn't accept numeric strings as anything
more meaningful than something to print as text.
Fix this (by wrapping it in a ParseException) to properly print:
```
meson.build:4: WARNING: Newline character in a string detected, use ''' (three single quotes) for multiline strings instead.
This will become a hard error in a future Meson release.
t = '
^
```
Eli Schwartz
Xavier Claessens
Christian Wendt
Tristan Partin
Dudemanguy
Jussi Pakkanen
Mark Bolhuis
Andrea Pappacoda
Dylan Baker
Paolo Bonzini
Christoph Reiter
Stone Tickle