There are still a lot of errors here due to a mixture of really bad
design (adding extra attributes to objects), and legitimate type errors
(passing a str where a List[str] is expected). I suspect a lot of these
cases aren't hit for some reason.
`configure_file` is both an extremely complicated implementation, and
a strange place for copying. It's a bit of a historical artifact, since
the fs module didn't yet exist. It makes more sense to move this to the
fs module and deprecate this `configure_file` version.
This new version works at build time rather than configure time, which
has the disadvantage it can't be passed to `run_command`, but with the
advantage that changes to the input don't require a full reconfigure.
Thanks to `ModuleInfo`, all modules are just named `foo.py` instead of
`unstable_foo.py`, which simplifies the import method a bit. This also
allows for accurate FeatureNew/FeatureDeprecated use, as we know when
the module was added and if/when it was stabilized.
We're going to do more with this in the next commit, but this just adds
the information for now. This allows the next commit have 100% mv
changes for some of the modules, which makes review easier
Instead of using FeatureNew/FeatureDeprecated in the module.
The goal here is to be able to handle information about modules in a
single place, instead of having to handle it separately. Each module
simply defines some metadata, and then the interpreter handles the rest.
(b, name) will always have the canonical tool name, not just a
potentially weird bin path. We need to check stderr for qt4 tools other
than lrelease, but we keyed off of the tool bin path, so matches were by
no means guaranteed, and specifically, would fail if the tool is looked
up via bindir.
This really should always have checked the canonical name, which is
guaranteed to be correct.
Partial fix for #10443
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...
For the same reasons commit 7aa28456d ("Add dependency type for
Valgrind") removed linking with valgrind, pkgconfig shouldn't generate
"Requirements" for it, in general.
This solves dbus meson port question/issue from:
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/303#note_1444819
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
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
The unit test was racy but surprisingly never failed on CI. The reason
is we need to ensure ninja build somelib.so before running `make` into
the external project.
We can use this lots of places, and it's always the same kwarg. There
doesn't seem to be a point in naming it badly, then evolving it to the
standard name in the one place it is currently used. This made it not
shareable.
At several points in the code base, f-strings are not correctly expanded
due to missing 'f' string prefix. This fixes all the occurrences I could
find.
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.
Logically, i18n.merge_file cannot ever take a MULTI_OUTPUT_KW, but it
does take a CT_OUTPUT_KW-like interface.
Actually trying to pass multiple merge_file outputs causes the
msgfmthelper script to be entirely malformed in the arguments it
accepts, and treat the broken one like a --flag, then exit with argparse
errors.
Even if we somehow assumed that somehow it was designed to actually
allow this, msgfmt doesn't support conceptually passing multiple outputs
so that would be a msgfmt error instead of an error inside the guts of
`meson --internal msgfmthelper`.
Same logic applies again for the itstool command and the itstool
internal helper.
Catch this error at configuration time by using the single-output kwarg
form.
Likewise, it's totally nonsense to accept multiple install_dir or
install_tags, and ever since commit 11f9638035
the CustomTarget itself won't even check this.
CT_OUTPUT_KW is the same OUTPUT_KW we use in lots of places. The most
distinctive thing about it is not that it's part of custom_target
(basically any other function that uses such a kwarg follows the same
rules due to using CustomTarget under the hood), but the fact that it
takes multiple outputs.
We validate a few things here, such as the non-presence of '@INPUT' in
an output name. These got moved out of the CustomTarget constructor in
commit 11f9638035 and into KwargInfo, but
only for kwargs that took multiple values. This caused configure_file()
and unstable_rust.bindgen() to stop checking for this.
Add a shared single-output KW and use it in both places. This now
dispatches to _output_validator.
configure_file now validates subdirectories in output names the same way
we do elsewhere, directly in the typed_kwargs and by specifying the
erroring kwarg.
For maintainer targets, we need some more tools that gettext-tiny
doesn't implement. It's a shame to cause NLS to be completely disabled
in such environments, so instead just issue a warning and continue.
Before 0.62.0 these were never checked for, and would simply fail at
runtime, probably. In theory, the user might install the tools in
between configuring and building, and then the maintainer targets would
begin to work. Return to that behavior -- we still create the targets,
which will *probably* fail, but might not -- and for existing
integrations, failing at `ninja foo-update-po` with "error, program
msgmerge not found" is a bit more discoverable than ninja saying "what
do you mean, there's no such target".
We still have the 0.62.0 preferred behavior of trying to find the
programs, succeeding in all cases other than gettext-tiny, and
guaranteeing that their paths are set up in a machine-file-respecting
manner.
In the former case, the presence of tools is optional, but triggers a
warning and then no-ops the target. In the latter case, the presence of
the tools is mandatory. But if it was already looked up and discovered
to be missing, we did not actually check that it is found before trying
to use it.
In the case that it isn't found, check again, so that we explicitly
error out with a relevant error message due to setting the required
flag.
Fixes#10320
python compiled extensions should never need to expose any symbol other
than PyInit_* which is declared with default visibility via
PyMODINIT_FUNC on supported compilers.
Thus, a reasonably sane default is to mark any other symbols as hidden,
while still respecting any manually specified visibility.
Gate this on the version of python itself, as not all versions decorate
PyMODINIT_FUNC properly.
On Python 3.8.x and later, if the imported module requires non-system DLLs that
are not installed nor bundled with the module package, os.add_dll_directory()
must be called on every path that contains the required DLLs, so that the module
can be imported successfully by Python.
Make things easier for people by calling os.add_dll_directory() on the
valid directories in %PATH%, so that such module checks can be carried out
successfully with much less manual intervention.
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.
The new get_env() method that returns an EnvironmentVariables object
will be needed in next commit that will pass it to CustomTarget.
This has the side effect to use the proper os specific path separator
instead of hardcoding `:`. It is the obvious right thing to do here, but
has caused issues in the past. Hopefully issues have been fixed in the
meantime. If not, better deal with fallouts than keep doing the wrong
thing forever.
Regression in commit 11f9638035. When
`install: true` the install_dir must be set. The CustomTarget
initializer no longer checks this for us, so we must include the check
ourselves.
Regression in commit 11f9638035. We expect
exactly one string as an install_dir, but CustomTarget started expecting
it to be a list. So we need to pass it as such when forwarding
compile_translations() arguments to the CustomTarget initializer.
Dylan Baker
Eli Schwartz
Richard Hughes
Marc-André Lureau
Olexa Bilaniuk
Xavier Claessens
Michael Mera
Chun-wei Fan
Ferdinand Thiessen