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 f291b637b1 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 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 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
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.
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
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 79c6075b56.
# 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.
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>
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".
There are two cases where we can assume we found the python dependency
with its requisite libraries using sysconfig:
- we found the library with find_library and are prepared to link to it
- the library is not actually part of the dependency, so its presence or
absence is irrelevant
In the latter case, we should consider it found if link_libpython is
False. Originally we did this, but the logic was inverted in commit
5b422fce87 in an unrelated change and
without explanation, likely by accident.
Normally this doesn't much matter, since a python invariably comes with
a predictably located libpython and the first condition evaluates true.
But that is not true for pypy, and in fact that is the reason the
link_libpython check was originally added in commit
1bd14b52b2.
Restore that original logic.
Fixes#8570
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.
A bunch of files have several T.TYPE_CHECKING blocks that each do some
things which could just as well be done once, with a single `if`
statement. Make them do so.
Disabling targets because the tools used to build them aren't available
is a pretty suspicious thing to do. Users who want this are probably, in
general, advised to check themselves whether it is possible to build
those targets with find_program(..., required: false)
The i18n.gettext() invocation is a bit unusual because the product of
running it is non-critical files, specifically, translation catalogs. If
users don't have the tools needed to build them, they may not be able to
use them either, because perhaps they have NLS disabled on their
platform or it's difficult to put it in the bootstrap path.
So, for this reason, it was made non-fatal and the message catalogs are
just not created, and the resulting build is still perfectly usable
*unless* you want to use it in another language, at which point it
"works" but the text is all inscrutable to the end user, and that's a
feature of the target platform.
That's an acceptable tradeoff for translation catalogs.
It is NOT an acceptable tradeoff for merge_file, which produces desktop
files or MIME database catalogs or other files which have crucial roles
to perform, without which the software in question simply doesn't work
at all. In such cases, this just fails to install crucial files, users
report bugs to the project in question, and the project adds
`find_program('xgettext')` to guarantee the hard error due to lack of
confidence in Meson.
Fixes#6165Fixes#8436
Use this instead of shutil.which to detect whether they will be
available, and pass the ExternalProgram object to CustomTarget
invocations, or else make use of the new functionality to specify the
correct program path in wrapper scripts.
Drop duplicate reporting for itstool missing. Since we use find_program
in required mode, its absence is already fatal, and already has a really
good error description.
Due to misuse of argparse in commit 82492f5d76
it was impossible to use both --datadirs and extra args passed directly
to msgfmt at the same time.
I'm not sure anyone actually knows how argparse works, so misusing it is
easy. What is definitely known is that argparse is NOT a POSIX compliant
parser and doesn't behave the way you'd expect a standards based parser
to handle options. Instead it caters to the easy use case, and hopes and
prays you don't need to do anything too complicated "with the wrong kind
of complicated".
Apparently, this particular type of complicated is when you have mixed
option_arguments and operands while simultaneously passing some operands
as nargs after a --.
It totally breaks, and interprets --datadirs, which is supposed to be an
option_argument, as an operand, eats it up as a msgfmt wrapped argument,
and breaks.
But if you don't pass additional arguments with -- then it interprets
--datadirs after operands as an option_argument. This is what we were
doing.
Instead pass option_arguments before all operands (including the ones
specified via `-- ...`). Add test case to pass meaningless datadirs (we
don't actually care if $GETTEXTDATADIRS is set to something that doesn't
contain gettext data).
- Change `scope` kwarg to `public` boolean default to false.
- Change `side` kwarg to `client` and `server` booleans.
- Document returned values
- Aggregate in a single unit test because have lots of small tests
increases CI time.
Fixes: #10040.
Fredrik Salomonsson
Eli Schwartz
Xavier Claessens
John Lindgren
Matti Picus
Jussi Pakkanen
Eli Schwartz
Jan Tojnar
Antoine Jacoutot
Dylan Baker
Paolo Bonzini
Ralf Gommers
Tristan Partin