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.
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
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.
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