This removes one line of stderr output per GObject Introspection file
processed, e.g.
g-ir-scanner: link: gcc -o Fwupd-2.0 Fwupd-2.0.o -L. -Wl,-rpath...
In commit 3dcc712583 we moved to
typed_pos_args. In the process, we deleted some code to specifically
raise an error if you use custom_target or generator outputs, instead
leaving it out of the typed pos args.
However, that support was specifically supposed to be there. It was only
an error in part of an if statement for handling old versions of
glib-compile-resources. The specific error it calls out is that we need
to manually parse the depfile at configure time, due to an external bug;
obviously this is impossible if the gresource is only created at build
time.
Reinstate the original error message check, and allow built outputs to
be used as compile_resources() inputs.
Fixes#10367
Just like some of glib tools, wayland-scanner can be defined in the
pkgconfig dependency variables. Share code between gnome and wayland
modules into ModuleState.
We need to setup the environment we pass to g-ir-scanner because it will
try to use pkg-config to find dependencies, and that must respect user
settings from machine file. Also make it use uninstalled pc files Meson
generated in the case dependencies, such as glib, have been built as
subproject.
This moves generally useful logic from GNOME module's
_get_native_binary() into find_program() implementation. We could decide
later to expose it as public API.
In commit 823da39909 we tried to fix
disappearing dependencies. Instead, we appended the replacement
dependencies to the existing ones. But this, too, was wrong. The
function doesn't return new dependencies... it returns a copied list
of all the dependencies, then alone of all parts of that API, expects to
overwrite the existing variable.
(Sadly, part of the internals actually uses the entire list for
something.)
As a result, we produced a repeatedly growing list, which eventually
scaled really badly and e.g. OOMed on gstreamer.
Instead, let's just replace the dependencies with the updated copy.
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
In commit 68e684d51f the function
signature was changed, but several places did not adapt. Additionally,
we now totally dropped the in-place update of gtkdoc's sole source of
dependencies, but didn't propagate them upward to assign the newly
collected dependencies anywhere.
Fixes building gtkdoc with internal dependencies and failing when
specified directly (when building the 'all' target with sufficiently
random parallelism, deps may be built on time).
Fixes:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008382https://gitlab.gnome.org/GNOME/libmediaart/-/issues/4
Commit a0cade8f introduced a typo and wrongly check for
gtk4-update-icon-cache twice.
If gtk4-update-icon-cache (gtk4) is not found, look for
gtk-update-icon-cache (gtk3) instead.
While gtk+-3.0 / gtk4 do exist, they have never provided the location of
the gtk-update-icon-cache program as a pkgconfig variable. Trying to
find one anyway, resulted in two things happening:
- a useless dep lookup
- a fatal-meson-warnings error and build failure because the
get_pkgconfig_variable() in question never existed
The desktop-file-utils package is a package solely providing some
command line programs, and has never provided a pkg-config file in the
first place, so this always logged that the dependency was not found and
fell back to normal find_program_impl(), although without
fatal-meson-warnings build errors.
Fixes#10139
In commit 68e684d51f the _get_link_args
function was modified from returning a list[str] of arguments, to a
tuple of both that and a modified copy of the entire target's
current/enhanced dependencies (why not just the new ones? I don't know).
However, the existing use of the function was not adapted to this
change, and tried to turn this entire tuple into a node of the command
line. Tuples cannot flatten to lists, and mesonlib.File or
HoldableObjects don't make good command line arguments.
As a result we errored out with:
ERROR: Argument (['-L/path/to/builddir/', '--extra-library=foo'], [<SharedLibrary 25a6634@@foo@sha: foo>, <SharedLibrary 25a6634@@foo@sha: foo>, <SharedLibrary 25a6634@@foo@sha: foo>]) in "command" is invalid
Split out the flags and the dependencies and update the former while
replacing the latter.
In commit c88bfdbefc we added support for
an exe_wrapper to gtkdoc, which checked twice whether the environment
says it is needed, and didn't check at all whether one was provided.
The result:
File "/usr/lib/python3/dist-packages/mesonbuild/modules/gnome.py", line 1354, in gtkdoc
t_args.append('--run=' + ' '.join(state.environment.get_exe_wrapper().get_command()))
AttributeError: 'NoneType' object has no attribute 'get_command'
Instead, check whether we have a valid exe_wrapper (if we don't need
one, then even when one is defined in the cross file, we get an
EmptyExternalProgram) and if we do, use it.
If we don't have one, but need one, then we revert back to the behavior
before commit c88bfdbefc, which probably
means "executing the doc target causes the command to error out with
"Exec format error".
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
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
There is the problem of the annotations themselves, then there is
the problem with depends being mutated. The mutation side effect is a
problem in itself, but there's also the problem that we really want to
use Sequence, which isn't mutable.
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
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>
The original attempted fix only allowed configuration to succeed, but
not building. It was modeled based on the gdbus-codegen documentation,
which states:
--annotate WHAT KEY VALUE WHAT KEY VALUE WHAT KEY VALUE
Add annotation (may be used several times)
which clearly indicates that gdbus-codegen accepts an --annotate flag
that is followed by a multiple of 3 values, despite this not actually
working.
The manpage actually contradicts the --help text:
--annotate ELEMENT KEY VALUE
Used to inject D-Bus annotations into the given XML files. []
... and gives examples that use multiple --annotate flags each with 3
arguments.
To better understand what meson is supposed to do here, we should look
at ef52e60936, which ported to
typed_kwargs. There is actually a big chunk of code to handle
annotations that got completely dropped, leading with a comment (that
did not get dropped): "they are a list of lists of strings..."
Reimplement this logic inside a validator/converter for the annotations
kwarg container:
- do not listify, we don't accept `annotations: ''` and listify is
supposed to be for when either x or list[x] is valid
- go back to checking for a list of exactly 3 values
- allow a list of the aforementioned, in the traditionally expected
form:
[
['foo1', 'foo2', 'foo3'],
['bar1', 'bar2', 'bar3'],
]
- pass one --annotate flag per 3-value-list
And add some better error reporting for the cause of errors when
processing lists of lists.
Richard Hughes
Eli Schwartz
Xavier Claessens
Dylan Baker
Ferdinand Thiessen
Eli Schwartz
Jan Tojnar
Antoine Jacoutot
Remi Thebault
Bilal Elmoussaoui