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.
Regression in commit 566c2c9a9c.
The interpreter details are a bit of black magic. Functions expect
tuples, but they receive lists and then the type-checking decorators
convert those to tuples.
So, directly manhandling a self._interpreter.func_*() but passing it the
tuple it nominally expected, actually explodes in your face by way of
failing an assert, then dumping 'ERROR: Unhandled python exception'.
Fixes use of gnome.gtkdoc(..., check: true), for example when building
glib.
In some cases, init variables that accept None as a sentinel and
immediately overwrite with [], are migrated to dataclass field
factories. \o/
Note: dataclasses by default cannot provide eq methods, as they then
become unhashable. In the future we may wish to opt into declaring them
frozen, instead/additionally.
The pip package is for python 3.6, but installs pip for all versions of
python. Apparently. Including python 3.7.
So do all other packages, especially the ones where it doesn't work but
pip thinks it is installed anyway. Force a reinstall.
Names used in init functions are sometimes pointlessly different from
the class instance attributes they are immediately assigned to. They
would make more sense if defined properly.
It is unmaintained, broken (frequently for long periods of time) and not
really required for any meson functionality. Its purpose is to be used
as a one-shot tool for creating a distro package recipe, and then
deleted from your meson.build files.
Due to its fragile dependency on coredata implementation details, we
cannot assume it will reliably work, or continue to work, without
someone who is actively willing to take responsibility for it.
Even if that were to happen, this might be better off as an external
script that parses introspection data.
Closes#9764Closes#9763
This is another toolchain also called `armclang`, but it is not a cross
compiler like Keil's `armclang`. It is essentially the same as `clang`
based on its interface and CMake's support of the toolchain.
Use an `armltd` prefix for the compiler ID.
Fixes: #7255
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
For a long time now, this has done 3 different things, only one of which
is mypy. But they are labeled:
- LintMypy / lint
(runs pylint)
- LintMypy / custom_lint
(runs a custom script)
- LintMypy / mypy
(actually runs mypy)
This reduces the usable length of the label which isn't all that long to
begin with, is actively misleading, and even when you know what is going
on, it becomes harder to tell at a glance what failed. Change it to be
more unambiguous.
In commit e5a6283c4c, this function was
reorganized to assign value -> newvalue instead of overwriting newvalue,
but the error message case wasn't updated to match. As a result,
actually hitting the error would report an even more errory error, i.e.
a traceback.
(Actually hitting the error requires passing an array option as a python
object that isn't a list or a string. This is impossible to do from the
command line or meson_options.txt, but can be done with builtin options.)
They claimed that all of these functions accepted any posargs or varargs
that install scripts supported. This was inconsistent with both the
types that meson currently allowed, and the types that we documented in
refman 1.0 *should* be allowed.
Take the opportuninty to be clear as refman 1.0 never was, about the
difference between types supported in the first posarg, and the ypes
supported in succeeding varargs.
In commit c239ce31f5 support was added to
these functions to accept various non-string types.
Despite the commit/PR documenting that only add_install_script is
permitted to accept built files, the actual check parameter was set, for
all three, to "True" (so the function was never invoked with False at
all). This meant that actually attempting to use the allowed types would
fail at postconf or dist, with python tracebacks in the former case and
"Failed to run dist script" in the latter case.
This was partially ameliorated in commit
6c5bfd4c24 which added typed_pos_args, but
unfortunately those typed_pos_args were all over the place.
For postconf:
- They banned external programs as additional args (which should be allowed)
- They banned built executables (good)
- They allowed custom targets as additional args (bad)
For dist:
- they allowed external programs (good)
- they allowed built executables, but only as the first argument (bad, also ???)
- they allowed custom targets, but only as additional arguments (bad, also ???)
Fix this all to only allow the same argument types for both the script
argument and the script-args arguments. That type is known at configure
time and restricted to source files, configured files, and found
programs.
In commit 2c0eaf5c4f support was added for
install scripts to accept found programs, built executables, or custom targets.
In commit c239ce31f5, this was extended to
dist and postconf scripts too (although it was documented that those
should not accept targets that are built by ninja).
Despite the commit/PR claiming that all of these should always accept
files and configured files, this was only true for arguments other than
the first, until commit f808c955ea.
In amongst all this, FeatureNew checks were never registered for the
first argument, only for additional arguments, until late in the game
with the addition of FeatureNew checks for File objects.
Fix this in part by moving the 3 different File checks into one, inside the
function that processes the first script, and make that function check
for FeatureNew on anything else too.
Eli Schwartz
Erik Faye-Lund
Dylan Baker
Michal Vasilek
Jussi Pakkanen
x-yuri
Itoh Shimon
Stone Tickle
John Kilpatrick
Ben Boeckel
Pablo Correa Gómez