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>
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.
It was generating #include with the basename of every header file. That
assumes that every directory where there are headers are also included
into search path when compiling the .c file.
Change to use path relative to current subdir, which can be both in
build or source directory. That means that we assume that when the .c
file is compiled, the target has a include_directories pointing to the
directory where gnome.mkenum_simple() has been called, which is
generally '.' and added automatically.
Also fix type annotation to only allow str and File sources, other types
have never been working, it would require to iterate over custom target
outputs, etc.
Fixes: #7582
In commit 89146e84c9 we added some
complicated code to verify the llvm framework's "combination" matrix
lookup. It expects to find llvm with both cmake and config-tool, with
the same version. But the sanity check is wonky -- it checks that both
have the same found status, instead, so if both are not found then we
proceed to try to convert the string "unknown" to a mapping of semver
integers, and this is guaranteed to fail.
This can happen for example if the system llvm exists in the general
case, but actual modules cannot be found because the system llvm does
not distribute static modules. For example, this is the case on Gentoo.
Abort more obviously by just insisting that both be found. If they
aren't both found, then investigative efforts know to look at why they
weren't found.
Currently you can only use one of qt4, qt5, qt6 in a single project
when using a machine file because the config-tool lookup for qt only
looks at `qmake` in the machine files, instead of looking up the
binary names directly.
Allow specifying `qmake` `qmake4` `qmake5` and `qmake6`.
This is necessary for gstreamer, which can build separate qt5 and qt6
plugins that are distributed as static libraries, so the user can pick
which one to use.
On Windows, the SDL2 library is generally provided with only CMake config
files. This commit allows meson to fallback on CMake as a last resort to
find the SDL2 library.
It was totally subproject-unsafe, and setting a super bad example. This
is bad, because doxygen is annoying to get right and we occasionally
tell people to go use our example test case.
There is a fun nuance here, that makes doxygen unpredictably work on
some versions, and fail on others. Specifically, values must be quoted
in doxygen 1.8, but not in doxygen 1.9, or they break -- but only if the
output directory contains spaces. This was "fixed" in commit
ef91bacb7a
which actually caused it to act like an unquoted OUTPUT_DIRECTORY is not
provided at all, and then fixed for real in commit
eb3d1eb5ad
For portability, it is necessary to quote this just to be on the safe
side.
Fixes#11579
gpgme has decided that config-tool is bad, which makes sense. They've
also decided that they will only install theirs, if gpg-error also
installs one, which is a bit... confusing. Anyway, it's impossible to
know whether it should or should not exist, so just accept that this
test is ready to be skipped on distros that currently no longer have
this ancient config-tool script.
Victory is within reach!
llvm-config is unsuitable for standard cross-compile,
because we need to build llvm especially for it, which
is not done is almost any distros, so, for example,
standard bootstrap chroot will be unsuitable.
This patch is trying to acheive feature parity between
config-tool searching of LLVM and CMake-based one,
which is arch-agnostic.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
This is no longer implicitly installed due to libxslt. Actually though,
we don't need to test this in order to ensure that the custom dependency
works -- we have other jobs that test it, and the config-tool handling
itself won't suddenly fail on msys2 specifically.
*.qrc files converted to C++ sources could make use of Qt headers, and
in practice for qt4 they seem to. Since this is Qt code to begin with,
it makes sense to depend on the Qt being targeted regardless of version.
GeneratedLists as sources to `gnome.gdbus_codegen` worked until
version 0.60 of Meson, but broke in 0.61 because of the conversion to
typed_pos_args and typed_kwargs. Reinstate this by adding them to the
decorators and annotations.
Note that gdbus_codegen desugars to two custom_targets and therefore the
generator is invoked twice. This is not optimal, but it should not be
an issue and can be changed later.
Fixes: 53a187ba2 ("modules/gnome: use typed_pos_args for gdbus_codegen", 2021-11-01)
Fixes: ef52e6093 ("modules/gnome: use typed_kwargs for gdbus_codegen", 2021-11-08)
Custom targets as sources to `gnome.gdbus_codegen` worked until version 0.60
of Meson, but broke in 0.61 because of the conversion to typed_pos_args
and typed_kwargs. Reinstate this by adding custom targets to the
decorators and annotations.
While generators also used to work, they are a bit tricky because
gdbus_codegen desugars to two custom_targets and therefore the generator
is invoked twice. This should not be a problem, but be explicit and
leave that to a separate commit to highlight the problem.
Fixes: 53a187ba2 ("modules/gnome: use typed_pos_args for gdbus_codegen", 2021-11-01)
Fixes: ef52e6093 ("modules/gnome: use typed_kwargs for gdbus_codegen", 2021-11-08)
The returned GResource is transfer-none, since the generated function
basically calls g_static_resource_get_resource(). It should not be
unreffed. Causes an abort on Debian:
GLib-GIO:ERROR:../../../gio/gresource.c:1451:g_static_resource_fini: assertion failed: (g_atomic_int_get (&resource->ref_count) >= 2)
Fixes regression in commit c211fea513. The
original dependency lookup looked for `qmake-{self.name}`, i.e.
`qmake-qt5`, but when porting to config-tool, it got switched to
`qmake-{self.qtname}` i.e. `qmake-Qt6`, which was bogus and never
worked. As a result, if `qmake-qt5` and `qmake` both existed, and the
latter was NOT qt5, it would only try the less preferred name, and then
fail.
We need to define self.name early enough to define the configtool names,
which means we need to set it before running the configtool __init__()
even though configtool/pkgconfig would also set it to the same value.
Mark the tests as passing on two distros that were failing to detect
qmake due to this issue, and were marked for skipping because we assumed
that the CI skipping there was an expected case rather than an old
regression.
The "frameworks/4 qt" test covers Qt 4 and 5. There is already Qt 6 code
in the test but it is incomplete because translations are missing and Qt
6 requires C++17 or later to compile.
Due to misuse of argparse in commit 82492f5d76
it was impossible to use both --datadirs and extra args passed directly
to msgfmt at the same time.
I'm not sure anyone actually knows how argparse works, so misusing it is
easy. What is definitely known is that argparse is NOT a POSIX compliant
parser and doesn't behave the way you'd expect a standards based parser
to handle options. Instead it caters to the easy use case, and hopes and
prays you don't need to do anything too complicated "with the wrong kind
of complicated".
Apparently, this particular type of complicated is when you have mixed
option_arguments and operands while simultaneously passing some operands
as nargs after a --.
It totally breaks, and interprets --datadirs, which is supposed to be an
option_argument, as an operand, eats it up as a msgfmt wrapped argument,
and breaks.
But if you don't pass additional arguments with -- then it interprets
--datadirs after operands as an option_argument. This is what we were
doing.
Instead pass option_arguments before all operands (including the ones
specified via `-- ...`). Add test case to pass meaningless datadirs (we
don't actually care if $GETTEXTDATADIRS is set to something that doesn't
contain gettext data).
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
It used to support:
- a single string
- an array of anything
And as long as CustomTarget supported it too, everything worked fine.
So, a `files('foo')` worked but a `files('foo')[0]` did not, which is
silly... and it's not exactly terrible to use files() here, the input is
literally a list of source files.
Fixes building gnome-terminal
Fixes#9827
Test updated by Nirbheek Chauhan <nirbheek@centricular.com>
check: true is needed for an actual regression test, but that requires
a pedantically correct gtk-doc configuration, which I attempted to do
and failed. So let's just put check: false so we get *some* coverage:
just that typed_kwargs accepts the argument.
Related to https://github.com/mesonbuild/meson/pull/9807
Charles Brunet
Eli Schwartz
Sam James
Nirbheek Chauhan
Xavier Claessens
George Sedov
Eli Schwartz
Volker Weißmann
Matthieu Bouron
Josh Soref
Konstantin
Paolo Bonzini
Jan Alexander Steffens (heftig)
Dylan Baker
Stefan Hajnoczi
Jan Tojnar
Matthias Klumpp
Pablo Correa Gómez