It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
This time we have a case where people are passing non-objects by using
them as str | File, which we never warned about and silently accepted.
If it was passed via custom_target outputs we *would* error out,
interestingly enough. At the backend layer, we just pass them directly
to the linker... which is valid, if we misdetected what's a valid linker
input or people just used funny names. In particular, the mingw
toolchain allows passing a *.def file directly, and some people are
doing that.
If we do want to allow this, we should do it consistently. For now, just
follow the current theme of what's expected, but do so by warning
instead of fatally erroring, for cases where users were able to do it in
the past.
In the case r1 -> s1 -> s2 where s1 and s2 are uninstalled C static
libraries, the libs1.a rule does not depend on libs2.a. That means that
r1 rule must depend on both s1 and s2.
We haven't actually verified that these kwargs are equal to what we had
before, and should probably revert the entire series. But I have
multiple reports in the wild of projects that no longer build because of
`install: [true, false, get_option('foobar')]` which was always
incorrect and always equal to just dropping values all over the floor
and treating it the same as "bool(value) == True".
Special case this particular typed kwarg and allow it with a sternly
worded warning that it was always wrong and should never ever ever be
done.
Fixes: https://bugs.gentoo.org/917118
Fixes: http://qa-logs.debian.net/2023/11/11/rhythmbox_3.4.7-1_unstable_meson-exp.log
Thanks to the Gentoo Tinderbox project, and Lucas Nussbaum of the Debian
project.
Pass link arguments directly down to linker by using `-C link-args=`
instead of letting rustc/linker resolve `-l` arguments. This solves
problems with e.g. +verbatim not being portable. Note that we also pass
`-l` args as `-Clink-args=-l` because rustc would otherwise reorder
arguments and put `-lstdc++` before `-Clink-args=libfoo++.a`.
However, when building a rlib/staticlib we should still use `-l`
arguments because that allows rustc to bundle static libraries we
link-whole. In that case, since there is no platform specific dynamic
linker, +verbatim works.
This also fix installed staticlib that now bundle uninstalled static
libraries it links to (recursively). This is done by putting them all
into self.link_whole_targets instead of putting their objects into
self.objects, and let rustc do the bundling. This has the extra
advantage that rustc can bundle static libries built with CustomTarget.
Disable bundling in all other cases, otherwise we could end up with
duplicated objects in static libraries, in diamond dependency graph
case.
Fixes: #12484
CustomTarget and CustomTargetIndex often have to be special cased
because they are not subclass of BuildTarget. It's easier to introduce a
dummy base class.
This fix recursive functions over link targets that might encouters
libraries built as CustomTarget.
The bug that is referenced in the SKIP message was merged in time for
the most recent llvm 16.x release. However, due to the graciousness of
the LLVM developers, a very reasonable response was taken:
LLVM will not merge ("the average"?) bugfixes during the final point
release of a release series, as judged by their willingness to continue
maintaining a major release of LLVM (????????) because merging a bugfix
could theoretically cause a new bug instead and that Simply Is Not
Done™. It could result in truly tragic outcomes, like having to release
another bugfix.
This innovative approach to bug solving has advanced the science of
computing forward by decades. Sadly, it comes at a downside: software
doesn't work. At this point it becomes obvious that llvm 16 in general
will simply not work with Meson, and this is "expected", so bump the
version checking for our SKIP to match reality.
If a tool that is looked up in a .pc file is supposed to be there and
has a pkg-config variable entry, but the value is incorrect, we can't
actually use it.
Since commit ab3d02066c we actually do run
the ExternalProgram search procedure on it though -- which caused it to
go wonky and return a None if it doesn't exist, instead of containing a
path to a program that does not exist and fails at build time. This is
better in the case where searching helps resolve .exe file extensions --
and worse in the case where patches to the dependency means nothing we
do is ever enough to actually find what is expected, since now we crash.
Raise an explicit error in such a case, pointing out that the dependency
itself is broken and needs a distributor-side resolution.
Fixes#12412
has_function_attribute() depends on -Wattributes being emitted when an attribute
is not supported by the compiler. In case of GCC on Window (at least) there is no
warning in case the attribute is used on a declaration. Only once there is also a
function definition does it emit a warning like:
a.c: In function ‘foo’:
a.c:8:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
8 | }
To fix this add a dummy function definition to all visibility compiler checks in meson.
The tests in "197 function attributes" only checked for positive return result on on-msvc
compilers, except one special case for dllexport/dllimport. Refactor the tests a bit so
one can specify also a negative expected result, and add tests for all visibility attribute
variants.
We try to backtrack through the filesystem to find the correct directory
to build in, and suggest this as a possible diagnostic. However, our
current heuristic relies on parsing the raw file with string matching to
see if it starts with `project(`, and this may or may not actually work.
Instead, do a bit of recursion and parse each candidate with mparser,
then check if the first node of *that* file is a project() function.
This makes us resilient to a common case: where the root meson.build is
entirely valid, but, the first line is a comment containing e.g. SPDX
license headers and a simple string comparison simply does not cut it.
Fixes the bad error message from #12441, which was supposed to provide
more guidance but did not.
When a user invokes the scan-build target that Meson generates
all subprojects are included in the resulting report. This commit
modifies the invocation of scan-build to exclude all bugs that
scan-build finds in the subprojects from the final report.
A release note has also been added describing the changed behaviour.
Reduce code duplication by iterating target.get_dependencies() instead
of iterating target.link_targets and target.link_whole_targets
separately. This has the extra benefit of taking into account
transitive dependencies.
- For indirect C ABI static libraries, this adds missing "-l static="
arguments.
- For indirect Rust ABI dependencies, this adds missing "-L" arguments.
- Verbatim modifier was used only for link_whole_targets, it's now
always used when available.
Fixes: #11694
Previously, AIX support was updated to archive shared libraries per AIX
platform conventions, which expect .a files that contain .so files. This
is usually correct, but an edge case occurs for loadable plugins, e.g.
what meson creates for `shared_module()`. A notable example is python
extensions (SciPy, for example).
These should *not* be archived, because the .so file itself needs to be
loaded as a plugin. For example, SciPy fails to import in the python
interpreter.
Handle this by differentiating between plugins and regular libraries,
and only archiving when safe to do so.
Fixes#12219
Previously, creating a meson wrap with "method=cargo"
for https://github.com/sunfishcode/is-terminal would fail,
because its Cargo.toml contains a [target] section without
dependencies.
Instead, we now fall back to an empty list in case of no specified dependencies
(like everywhere else in "_convert_manifest")
Regression in commit a3d287c553.
When a given kwarg is not specified, we want to not generate it as a
simd variant. Since the default for buildtarget sources is `[]` it
resulted in building a static library with no sources, and a warning
stating that this was buggy and will eventually be removed.
Fix this by teaching buildtarget sources to allow None, and defaulting
to it specifically for the simd module. We can check this and then skip
processing entirely.
Fixes#12438
Certain envs may not support invoking itstool by itself directly as a script
as shebang lines are not supported, such as under cmd.exe shells on Windows,
that are normally used for Visual Studio (and the like, such as clang-cl)
builds.
This will call the corresponding interpreter to invoke itstool when needed, so
that itstool can be properly run, even if shebang lines are not supported by
the env.
This will fix building appstream on Windows using clang-cl, for instance.
adb1a360b9 added the feature and also the
usual meson-style warning to users that might be using the feature but
were not targeting a new enough meson version. Well unfortunately the
warning both doesn't actually work (it didn't take different directories
into account) and is also really slow because it creates an O(N^2) loop
for checking this.
Instead, rework this by adding an additional set that stores a tuple
containing the target name and its subdirectory. We only add this tuple
if the target is an executable since it is the only time it will be
relevant. After that, simply check if the name + subdir combination
already exists in the set along with the target being executable. If so,
then we execute FeatureNew which may possibly warn. This is a simply
O(1) lookup which is way faster. Fixes#12404.
Partially reverts commit 1624354f33 which
moved a bunch of stuff from strings to enums. The issue here is that
Compiler.mode is not just, or primarily, something we compare, but is
instead written in as e.g. `rule c_{compiler.mode}` to build.ninja, so
this identifier needs to be a string.
Ultimately, the issue is that the commit tried to rewrite a bunch of
things called "mode" that had a couple of TODOs saying to use enums...
but it rewrote everything called "mode" regardless of whether it was a
function kwarg or a compiler property, even though the TODO only applied
to one of them.
albert
Marcel Telka
Eli Schwartz
Jussi Pakkanen
Dylan Baker
Xavier Claessens
Michael Gene Brockus (Dreamer)
Christoph Reiter
Andrew McNulty
Sebastian Dröge
Aditya Vidyadhar Kamath
Luke Elliott
Alaska
Chun-wei Fan
Dudemanguy
Eli Schwartz
Tristan Partin