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
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.
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
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.
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.
This does require hacking up the test pretty badly, since we need to not
ever pass GCC these invalid values. But it's preferable to writing
another project test I think.
Co-Authored-by: Nirbheek Chauhan <nirbheek@centricular.com>
Which allow passing arguments specifically to the static or shared
libraries.
For design, this is all handled in the interpreter, by the build layer
the arguments are combined into the existing fields. This limits changes
required in the mid and backend layers
Way back in Meson 0.25, support was added to `vala_args` for Files.
Strangely, this was never added to any other language, though it's been
discussed before. For type safety, it makes more sense to handle this in
the interpreter level, and pass only strings into the build IR.
This is accomplished by adding a `depend_files` field to the
`BuildTarget` class (which is not exposed to the user), and adding the
depend files into that field, while converting the arguments to relative
string paths. This ensures both the proper build dependencies happen, as
well as that the arguments are always strings.
When checking target names, meson explictly forbids having multiple
targets with the same name. This is good, but it is strict and it is
impossible to have targets with the same basename and differing suffixes
(e.g. foo and foo.bin) in the same directory. Allow this for executables
by including the suffix (if it exists) in the interal target id. So foo
would be foo@exe and foo.bin would be foo.bin@exe.
This should be an error, not an assert as it asserts nothing,
in fact, if this wouldn't error out because of the wrong type
passed to the assert, it would even do the wrong thing.
Follow-up to #12223
Testing the correctness of the `modules: ` kwarg can be done with other
guaranteed stdlib modules that are even more guaranteed since they
didn't get deprecated for removal.
Charles Brunet
Eli Schwartz
Sam James
Stas Sergeev
Alyssa Ross
Peter Urban
Jonathon Anderson
L. E. Segovia
Valeri
Tamás Bálint Misius
Sergey Vlasov
Dylan Baker
Nicolas Werner
arch1t3cht
Andres Freund
Randy Eckenrode
Xavier Claessens
David Seifert
Jussi Pakkanen
Christoph Reiter
Sebastian Dröge
Nirbheek Chauhan
Tristan Partin
Nomura
Dudemanguy
Marvin Scholz
Alan Coopersmith