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.
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".
Eli Schwartz
Dylan Baker
Chun-wei Fan
Xavier Claessens
Ferdinand Thiessen
Fredrik Salomonsson
John Lindgren
Matti Picus
Jussi Pakkanen
Eli Schwartz
Jan Tojnar
Antoine Jacoutot
Paolo Bonzini
Ralf Gommers
Tristan Partin