When linking with a Rust rlib, we should also link with its external
system dependencies. This was currently done only for C ABI crates, do
it for both rlib and staticlib now.
musl 1.2.5 exposes this symbol in the default profile, and in future
will expose it unconditionally, as it is on track to becoming part of
POSIX.
So rather than maintaining a list of systems to run this on, let's
just skip testing the feature test macro if we find ppoll in the
default profile.
When the proc-macro rlib is in a different subdir, it would miss the
needed -L argument and rustc would not find it. Meson was assuming that
proc-macros are only needed when building libraries that uses it, but it
turns out that was wrong, as show by the unit test.
Cargo implements this configuration option to override the entry point
of the library.
To get test coverage, I've modified one of the two Cargo subprojects
in the test to use a non-default library entrypoint. The other still
uses the default.
This code cleverly tried to use a fancy new pathlib.Path method to get
the os.path.commonpath of two paths and check whether one is inside the
other. It failed pretty badly, because of a hidden secret of pathlib: it
is designed to throw random exceptions at all times (except when
building os.PathLike interfaces) instead of performing useful work.
Return to `os.path`.
In particular, before this change, we wanted to check if files are NOT
in a subpath of `preserve_path_from`, and raise a meson "ERROR: xxx" in
such a case. However, the code to check for it would raise a python
ValueError if that was the case, so we never got to the properly
formatted error.
0e7fb07 introduced a subtile bug in the Python module.
If a python version is found, but is missing a required module,
it is added to the list of python installations, but the
`run_bytecompile` attribute for that version was not initialized.
Therefore, if any other python version added something to install, it
was raising a KeyError when trying to read the `run_bytecompile`
attribute for the python version with missing module.
On the openSUSE builder, we got a horrifying CI failure like:
```
FAILED: asubdir/subdir-prog.p/main.cpp.o
c++ -Iasubdir/subdir-prog.p -Iasubdir '-I../test cases/frameworks/5 protocol buffers/asubdir' -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -O0 -g -DPROTOBUF_USE_DLLS -DNOMINMAX -MD -MQ asubdir/subdir-prog.p/main.cpp.o -MF asubdir/subdir-prog.p/main.cpp.o.d -o asubdir/subdir-prog.p/main.cpp.o -c '../test cases/frameworks/5 protocol buffers/asubdir/main.cpp'
In file included from /usr/include/google/protobuf/stubs/common.h:20,
from /usr/include/google/protobuf/io/coded_stream.h:107,
from asubdir/subdir-prog.p/defs.pb.h:26,
from ../test cases/frameworks/5 protocol buffers/asubdir/main.cpp:1:
/usr/include/absl/strings/string_view.h:52:26: error: ‘string_view’ in namespace ‘std’ does not name a type
52 | using string_view = std::string_view;
| ^~~~~~~~~~~
[...]
```
This turns out to be because of a *huge* mess with abseil-cpp and protobuf. We're
still trying to handle it in Gentoo, even (see bgo#912819) and https://github.com/gentoo/gentoo/pull/32281.
In summary, abseil-cpp started to require C++17 (unless built with a special option
which causes ABI problems). Let's switch the protobuf test case to use C++17
accordingly. There's some precedence for Just Doing This, like in cb54f0d707
recently for Boost, and 792a84199b previously for
protobuf itself.
Bug: https://bugs.gentoo.org/912819
See also: https://github.com/gentoo/gentoo/pull/32281
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
We may want to consider our own binpkg cache for future to speed things up,
in addition to the ones provided by Gentoo's own binhost.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Apple Clang defaults to C++03 or earlier, and boost 1.84 has started
requiring C++11 as a minimum. Fixes test failures on the macOS builders.
Unneeded for GCC systems since GCC defaults to a more recent std -- but
also semantically correct there too.
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
Meson will implicit rpaths when *.so/*.dll/etc. files are injected onto
the link line from pkg-config and (now) cmake dependencies.
Extend the "prebuilt shared" tests to test that these are added.
GENERATED files can be used as dependencies for other targets, so it's
misguided (at best) to filter them with a blunt whitelist.
However, there does exist an extension that needs to be skipped: on Windows +
MSVC, CMake will by default try to generate a Visual Studio project, and
there dependencies with no inputs are instead tied to a dummy .rule
input file which is created by the generation step. The fileapi will
still report those, so it will cause Meson to bail out when it realises
there's no such file in the build tree.
Fixes#11607
* Vala: depend on gresources
Valac uses gresource at compile time to look up .ui files
* Automatically pass `--gresourcesdir` to valac
* gnome.compile_resources: clean up duplicate paths better
* Add a test for improved gresouce handling
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
This properly sets the project version in projects meson generates from
cmake projects. This allows dependency fallbacks to properly check the
version constraints in dependency calls when falling back to a cmake
subproject. Before this would fail, because the project version was
undefined.
This was originally added for vala only, with the rationale that vala
generates bad code that has warnings. Unfortunately, the rationale was
fatally flawed. The compiler warns about a number of things, which the
user can control depending on their code (or their code generator's
code), but some of those things are absolutely critical to warn about.
In particular, GCC 14 and clang 17 are updating their defaults to warn
-- and error by default for -- invalid C code that breaks the standard,
but has been silently accepted for over 20 years "because lots of people
do it". The code in question is UB, and compilers will generate faulty
machine code that behaves erroneously and probably has a mass of CVEs
waiting to happen.
Compiler warnings are NOT safe to just... universally turn off. Compiler
warnings could be either:
- coding style lints
- threatening statements that the code is factually and behaviorally wrong
There is no magic bullet to ignore the former while respecting the
latter. And the very last thing we should ever do is pass `-w`, since
that causes ALL warnings to be disabled, even the manually added
`-Werror=XXX`.
If vala generated code creates warnings, then the vala compiler can
decrease the log level by generating better code, or by adding warning
suppression pragmas for *specific* issues, such as unused functions.
The new linker in Sonoma / Xcode 15 considers the dependency via the
initializer sufficient to pull in the library. The man page now notes:
The linker never dead strips initialization and termination routines.
They are considered "roots" of the dead strip graph.
I could not find a good way to skip only if the linker version is new
enough. Before long everyone will be using the new linker anyway...
This was encountered while looking into an issue with
https://github.com/NixOS/nixpkgs/pull/268583.
I run my Nix store on case-sensitive APFS, so the test fails due to
trying to link `-framework ldap` instead of `-framework LDAP`.
This is needed now that str.format() is not allowing it any more. It is
also more consistent with other objects that have that method as well,
such as build targets.
Fixes: #12406
* unity builds: correct integer ceiling division
* edge case failure with unity builds:
- static archive bar that gets installed, that links with another static
archive foo that does not get installed
- the number of files in static archive foo is divisible by unity_size
would yield an error with ninja:
ninja: error: 'subprojects/foo/src/libfoo.a.p/meson-generated_foo-unity1.cpp.o', needed by 'src/libbar.a', missing and no known rule to make it
* unity builds: test for build failure when #files is divisible by unity_size
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
Charles Brunet
Xavier Claessens
Alyssa Ross
Jussi Pakkanen
L. E. Segovia
Tristan Partin
Karol Herbst
Dylan Baker
Eli Schwartz
Jouke Witteveen
Sam James
Stas Sergeev
Peter Urban
Jonathon Anderson
Valeri
Tamás Bálint Misius
Sergey Vlasov
Nicolas Werner
arch1t3cht
Andres Freund
Randy Eckenrode
David Seifert