Fedora has switched to zlib-ng, which has a version of `1.3.0.zlib-ng`,
causing AllPlatformTests.test_summary to fail. dl is much less likely to
change format.
We have two copies of other.h, one of which is generated. If we don't
include the include/ directory then building fails unless the
custom_target which copies it over, happens to run early enough. On
parallel builds this may fall on its face.
Only Environment and ConfigurationData are mutable. However, only
ConfigurationData becomes immutable after first use which is
inconsistent.
This deprecates modification after first use of Environment object and
clarify documentation.
Some tests for `gnome.mkenums_simple` were only compiled, but not run.
Most bugs will be caught by compilation alone, but it's better to run
the generated binary too in case there are runtime issues in the
generated code.
The naming of all enum tests is now unified as well.
They were skipped with llvm 17 based on the version, and they are
now no longer skipped with v18 and also pass now.
This depends on #12964 for llvm 18 support in meson.
The test.json format currently has three keys related to skipping tests:
* `skip_on_jobname`
* `skip_on_os`
* `skip_on_env`
While `skip_on_env` marks the test itself as skipped, i.e. they don't get run when the
conditions are met, the other two skip options are just marking the test as "expected to be skipped"
if the conditions apply, i.e. they want to see `MESON_SKIP_TEST` in the output and things will
fail if that doesn't happen. They don't actually skip the tests as the names imply.
To make this clearer rename the keys:
* `skip_on_jobname` -> `expect_skip_on_jobname`
* `skip_on_os` -> `expect_skip_on_os`
`skip_on_env` stays the same, since that actually skips.
The docs were also confused about this, so adjust that too.
By adding the option name to UserOption object, it is now possible to
display the name of the affected option when the given option value is
not valid.
Fixes#12635
Otherwise internal dependencies have auto-generated names that are not
human readable. Instead, use the name that the dependency overrides. For
example:
```meson
meson.override_dependency('zlib', declare_dependency())
dep_zlib = dependency('zlib')
assert(dep_zlib.name() == 'zlib')
```
Fixes: #12967
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.
Dylan Baker
Tristan Partin
Ben Corby
Eli Schwartz
Xavier Claessens
Jussi Pakkanen
L. E. Segovia
Matthijs Velsink
Charles Brunet
Gerion Entrup
Christoph Reiter
Alyssa Ross
Karol Herbst
Jouke Witteveen
Sam James