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.
As soon as we check for args[1] we declare it is of type FileOrString,
and the additional ones specified in the `sources` kwarg explicitly
allow this. It makes no sense to not accept it as the posarg too.
Fixes building tracker-miners.
Fixes gtk3 build, which uses typesfile.
All these arguments are processed by a function that explicitly handles
both str and File, and converts them to absolute paths. They clearly
need to handle File objects.
Per the gdbus-codegen documentation, this "may be used several times",
and it is:
- a valid use case
- used that way in the wild
Fixes building at least geoclue2, gdm.
This is basically a rewrite of the gnome.yelp target to remove the
ad-hoc script, which generates multiple issues, including meson
not knowing which files were installed.
Closes#7653Closes#9539Closes#6916Closes#2775Closes#7034Closes#1052
Related #9105
Related #1601
These are actually just flags, they don't take any arguments (except
prefix, which was already handled correctly), and as such their
arguments should be booleans, not strings, and they should default to
False.
There is a change here, in that packages has error messaging for using
IncludeDirs objects in the packages argument, but it never worked, so
the message was useless.
There are thee arguments that are passed directly to CustomTarget which
are not in the permittedKwargs: depends, depend_files, and build_always.
The first two are obviously generically useful, as they allow creating
correct ordering. The latter, not so much. Since it was an error to pass
it, we'll just delete it.
Use a proper install option for this. Now `install_<type>` can directly
override `install` instead of passing a boolean to the string kwarg
`install_dir_<type>`.
generate_gir forces building both the typelib and gir, and some people
only want one or the other (probably only the typelib?) which means
flagging the other as install_dir: false in the same way custom_target
supports.
As this always worked, albeit undocumented, make sure it keeps working.
It's pretty reasonable to allow, anyway.
Fixes https://github.com/mesonbuild/meson/pull/9484#issuecomment-980131791
Make it possible to specify a wrapper for executing binaries
in cross-compiling scenarios.
(usually, some kind of target hardware emulator, such as qemu)
Eli Schwartz
Dylan Baker
Remi Thebault
Xavier Claessens
Bilal Elmoussaoui
Michal Vasilek
Pablo Correa Gómez
Alexander Kanavin