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 = '
^
```
A backslash-escape of the last newline before a run of whitespace
leading to the indented string ending and function termination `)` does
not actually escape the entire line and make it do nothing. In fact what
it does is cause all that whitespace to be part of the preceding line,
and get printed.
Meanwhile the textwrap.dedent documentation states that lines with only
whitespace get normalized. When you *don't* mess with that final line,
dedent actually does the right thing and makes the output message end
with a single newline after the important text.
Do not report a MesonBugException if the command is `runpython`, because
that is 100% other people's code, not ours. It's only used as an
alternative to sys.executable for reporting a path to python, in the
event of a Windows MSI install.
While we are at it, refactor the logic for PermissionError to be a bit
more unified (and sadly use isinstance instead of except, but it is what
it is).
stdout line matching supports count since commit
66d62a224e to fail if certain output is
present (count: 0) but it was never documented in the contribution
guidelines.
Automatically generate additional variables and write them into the
generated pkg-config file.
This means projects no longer need to manually define the ones they
use, which is annoying for dataonly usages (it used to forbid setting
the base library-relevant "reserved" ones, and now allows it only for
dataonly. But it's bloat to manualy list them anyway).
It also fixes a regression in commit
248e6cf473 which caused libdir to not be
set, and to be unsettable, if the pkg-config file has no libraries but
uses the ${libdir} expansion in a custom variable. This could be
considered likely a case for dataonly, but it's not guaranteed.
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.
We currently cannot make this work because inside dependency() we don't
know the current subproject. We would also like the optional but
extremely useful location node, but we don't have that either...
Convert the broken code to a FIXME for visibility.
Use a derived type when passing `subproject` around, so that mypy knows
it's actually a SubProject, not a str. This means that passing anything
other than a handle to the interpreter state's subproject attribute
becomes a type violation, specifically when the order of the *four*
different str arguments is typoed.
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.
Do not quit from using pytest at all, when pytest is present, simply
because xdist isn't available. Even without xdist, pytest is still
useful.
There doesn't seem to be any particular reason to require xdist. It just
happens to have been implemented that way, back in commit
4200afc74d when we originally added a
check to avoid pytest erroring out with unknown options when xdist
options are passed and xdist is not installed.
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`".
Fixes regression in commit 05b5a1e56f.
This added usage of another module in the python module's introspection
of `meson.exe runpython`, but the MSI packaging didn't adapt, causing it
to fail to be detected due to ImportError.
Fixes#9975
We do not want anyone touching this entire directory tree, but due to
the way it was implemented, we only checked if its direct parent was a
subproject violation. This generally worked, unless people tried to add
`subprojects/` as an include directory.
Patch this hole. It now provides the same warning any sandbox violation
does (but is not currently an error, just a "will become an error in the
future").
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 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
The first version of setuptools to properly support pyproject.toml was 42 (40-41 were buggy). It is also necessary to specify `build-backend = "setuptools.build_meta"`, otherwise you get the (horrible) default `build-backend = "setuptools.build_meta:__legacy__"`.
This adds 3.10 (didn't check to see if it was tested on 3.10, that should be done, but I'm using it on 3.10).
setup_requires is deprecated and should be producing warnings on modern setuptools, and never worked for setuptools anyway - setuptools can't update itself, and setuptools is what is reading this anyway!
This will really help with pipx run, as `pipx run meson[ninja]` will now work on any system with pipx 0.17 or newer, no dependencies required. This now includes GitHub Actions, which just updated to pipx 1.0.0. Pipx run lets you use recent (always <1 week old) versions of anything on PyPI.
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
Dylan Baker
Eli Schwartz
Paolo Bonzini
Christoph Reiter
Stone Tickle
Nirbheek Chauhan
apoorv569
andy5995
Alyssa Ross
Jan Tojnar
Henry Schreiner