| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 11f96380351a88059ec55f1070fdebc1b1033117
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 11f96380351a88059ec55f1070fdebc1b1033117 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
|
|
Because this is a wrapper script and we could/should do this, we even
have half the infra for it.
|
|
|
|
That come to light with some of the changes later in this series,
particularly around dependencies.
|
|
|
|
As we commonly do in other modules
|
|
|
|
|
|
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 11f96380351a88059ec55f1070fdebc1b1033117. 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 11f96380351a88059ec55f1070fdebc1b1033117. 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.
|
|
|
|
If set to true it will generate the pkgconfig files as relocatable i.e
the prefix variable will be relative to the install_dir. By default
this is false.
Will generate a MesonException if the pkgconfig file is installed
outside of the package and pkgconfig.relocatable=true.
|
|
In commit f291b637b13ba32e20d1081906e68780d2a5ae5a the tools were moved
around but a comment got forgotten. Now, in order to be meaningful and
remind us of anything, it needs to be in a different location.
|
|
|
|
Although Qt6 has decided these are "internal" commands and should never
be run directly, so they don't get symlinked to /usr/bin at all, and are
only available in the qt_dep.bindir anyway.
But, the general naming pattern should be followed on principle.
|
|
Qt 6.1 moved the location of some binaries from QT_HOST_BINS to
QT_HOST_LIBEXECS as noted in the changelog:
c515ee178f Move build tools to libexec instead of the bin dir
- Tools that are called by the build system and are unlikely to be
called by the user are now installed to the libexec directory.
https://code.qt.io/cgit/qt/qtreleasenotes.git/tree/qt/6.1.0/release-note.txt
It's possible to help the 'qt' module find the tools by adding Qt's
libexec directory to the PATH environment variable, but this manual
workaround is not ideal.
To compensate, meson now needs to look for moc, rcc, uic, etc. in
QT_HOST_LIBEXECS as well as QT_HOST_BINS.
Co-authored-by: Stefan Hajnoczi <stefanha@jammr.net>
|
|
|
|
This is more reliable as '-c' can, for example, exhaust
the maximum command line length.
|
|
This check was erroneously removed in commit c5c02b72e132a03ae0284bdd5e15d1675301a37d
|
|
This reverts commit 7954a4c9cbf8355d8c8ea9b3d98df45d9f96f66e.
|
|
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.
|
|
They are RunTargets because they are one-shot commands without outputs.
But we implement them purely via our internal wrapper for gettext, so
there is no reason to wrap them *again* in our internal wrapper for
meson_exe and set a bunch of environment variables we know we absolutely
do not need, use, or want.
This avoids the ugly "wrapped due to env" status, and allows users to
directly see the command being run without going into despair at obscure
pickled nonsense.
It also offers a tiny defense against upgrading Meson without
reconfiguring. People should not do that, and we error out about this in
a bunch of places, but `--internal gettext` has a perfectly stable
interface just like most build tools that aren't part of Meson
internals, since it uses command line arguments instead of pickling.
|
|
In commit 823da3990947a8f4a2152826f0d7229f8a7a0159 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.
|
|
|
|
The `-framework Foundation -framework CoreFoundation` ended up
de-duplicated by OrderedSet into `-framework Foundation CoreFoundation`.
|
|
This was introduced in https://github.com/mesonbuild/meson/commit/823da3990947a8f4a2152826f0d7229f8a7a0159
|
|
In commit 68e684d51f1e469e0d9f4b499ffda15146cad98a 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=1008382
https://gitlab.gnome.org/GNOME/libmediaart/-/issues/4
|
|
Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
|
|
We cannot use typed_kwargs though, because we allow fully arbitrary
kwargs and pass them as arguments to the hotdoc program.
|
|
We cannot use typed_kwargs though, because we allow fully arbitrary
kwargs and add them as keys in the generated dub file.
|
|
Yes, it's deprecated, but we can still stop people doing the wrong thing
with it if they are still using it.
|
|
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.
|
|
Which we pretty obviously need if any of our headers are generated
|
|
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
|
|
It was originally added because proper detection was not working on
Debian, but that has been fixed since. It was causing annoying warning
by default when prefix is /usr/local that can only be avoided by setting
options.
|
|
This reverts commit 79c6075b560dbf1c3e4e0b30f1c472dc2086421e.
# Conflicts:
# docs/markdown/snippets/devenv.md
# mesonbuild/modules/python.py
# test cases/unit/91 devenv/test-devenv.py
PYTHONPATH cannot be reliably determined. The standard use case for
installing python modules with Meson is mixed pure sources (at least
`__init__.py`) and compiled extension_modules or configured files.
Unfortunately that doesn't actually work because python will not load
the same package hierarchy from two different directories, one a source
directory and one a (mandatory) out of tree build directory.
(It kind of can, but you need to do what this test case accidentally
stumbled upon, which is namespace packages. Namespace packages are a
very specific use case and you are NOT SUPPOSED to use them outside that
use case, so people are not going to use them just to circumvent Meson
devenv stuff as that would have negative install-time effects.)
Adding PYTHONPATH anyway will just lead to documentation commitments
which we cannot actually uphold, and confusing issues at time of use
because some imports *will* work... and some will *not*. The end result
will be a half-created tree of modules which just doesn't work together
at all, but because it partially works, users attempting to debug it
will spend time wondering why parts of it do import.
For any case where the automatic devenv would work correctly, it will
also work correctly to use `meson.add_devenv()` a single time, which is
very easy to manually get correct and doesn't provide any significant
value to automate.
In the long run, an uninstalled python package environment will require
"editable installs" support.
|
|
Keep conditions first, then "if true" fields, and the if_false sources last.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Dependencies in the "if_true" keyword argument do not prevent the
sources from being used; in other words, they work just like dependencies
with "disabler: false".
However, this was broken in commit ab0ffc6a2 ("modules/sourceset: Fix
remaining typing issues", 2022-02-23) which changed logic instead of
just fixing typing issues. This was likely an attempt to avoid using
"dependencies.Dependency" after the "dependencies" field was declared,
but it also broke QEMU.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The dependencies field clashes with the dependencies module, so that
mypy interprets "dependencies.Dependency" as a "Dependency" attribute
of the "dependencies" field.
Rename the field to something else, so that it does not clash.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
