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
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.
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).
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.
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
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.
This is gross and looks terrible, but I'm not entirely sure how else to
do this.
And cmake is an inferior methodology, TBH, since it is effectively the
same as our own builtins. However, cmake also handles some bizarre
Windows library names whose provenance I'm not entirely sure of, in
addition to implementing the usual excessive pattern of hardcoded search
directories. So, this may be useful, at least on Windows, as a fallback.
(I am not really interested in offering feature compatibility with cmake
for a bunch of bizarre naming schemes that ***aren't the official cmake
library names***, so if cmake allows that and people really feel they
need it, all the more power to them.)
Nevertheless, I believe if it got found via our system dependency class,
it will always provide results which are just as functional as cmake.
cmake can only find openssl installations that would otherwise be
missed.
This also avoids the case where users did
```
dependency('OpenSSL', modules: [...], method: 'cmake')
```
and expected it to work, since our builtin dependency supersedes the
divergent case and didn't previously allow the cmake method. I don't
know why they would do such a thing, but who knows... it is always
possible.
On some platforms, this is provided by the base system, which
nevertheless refrains from providing the .pc files that go along with
it. As a result, it's impossible to sensibly find these dependencies.
I'm looking at you, FreeBSD...
Upstream tracking bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659
This is also a problem on macOS, but that's unfixable (and I believe
they provide some truly ancient and out-of-support version anyway) and
you probably want to use the homebrew OpenSSL. Still, meson can now
detect these old versions and even set their version number.
CMake's write_basic_package_version_file has supported since version 3.14
an ARCH_INDEPENDENT option that makes it skip its architecture check in
the Version file.
With this patch Meson now supports it as well, and the change is also
compatible with older CMake versions, as they will simply ignore the
option.
This also slightly changes the contents of the generated Version file
when arch_independent is not set: previously, the if() needed to skip
the arch check was always filled with an empty string, while CMake puts
"FALSE" (or "TRUE") in it. Now, that if() will always be filled with
either "False" or "True", better matching CMake's behaviour.
This was a nice idea in theory, but in practice it had various problems:
- On the only platform where ldconfig is expected to be run, it is
really slow, even when the user uses a non-default prefix and ldconfig
doesn't even have permission to run, nor can do anything useful due to
ld.so.conf state
- On FreeBSD, it bricked the system: #9592
- On cross builds, it should not be used and broke installing, because
ldconfig may not be runnable without binfmt + qemu: #9707
- it prints weird and confusing errors in the common "custom prefix"
layout: #9241
Some of these problems can be or have been fixed. But it's a constant
source of footguns and complaints and for something that was originally
supposed to be just "it's the right thing to do anyway, so just do it
automatically" it is entirely too risky.
Ultimately I do not think there is justification for keeping this
feature in since it doesn't actually make everyone happy. Better for
users to decide whether they need this themselves.
This is anyways the case for cmake and autotools and generally any other
build system, so it should not be too intimidating...
Fixes#9721
Store in TestSerialisation whether a particular test must always be logged
verbosely. This is particularly useful for long-running tests or when a
single Meson test() is wrapping an external test harness. In this case,
TAP can be used by the external harness and Meson will log each subtest as
it runs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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.
Christoph Reiter
Eli Schwartz
Nirbheek Chauhan
apoorv569
andy5995
Alyssa Ross
Jan Tojnar
Tobias Pankrath
Jussi Pakkanen
Ole André Vadla Ravnås
Daniel Mensinger
Nazar Mokrynskyi
Zach Reizner
William Toohey
Andrea Pappacoda
Andrew Krasavin
Paolo Bonzini
Xavier Claessens
Dylan Baker