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.
We can immediately short-circuit if there is no destdir, as we simply
return the prefix unchanged.
If there is some kind of destdir and the prefix contains a drive letter,
then no matter what we need to remove the drive letter before joining.
Technically, if the destdir is a relative path e.g. `destdir\` and
`C:\prefix`, we should still install to `destdir\prefix` without the
drive letter.
But... we also guarantee that destdir is an absolute path (or empty)
anyway. And even if we didn't, non-absolute destdir is a broken concept
for a variety of complicated reasons. So none of this matters in
practice.
One way or another, we don't need to actually check whether destdir is
an absolute path before cutting off the prefix drive letter.
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.
This allows tracking which subproject it came from at the time of
definition, rather than the time of use. As a result, it is no longer
possible for one subproject which knows that another subproject installs
some data files, to expose those data files via its own
declare_dependency.
There are somewhat common, reasonable and legitimate use cases for a
dependency to provide data files installed to /usr which are used as
command inputs. When getting a dependency from a subproject, however,
the attempt to directly construct an input file from a subproject
results in a sandbox violation. This means not all dependencies can be
wrapped as a subproject.
One example is wayland-protocols XML files which get scanned and used to
produce C source files.
Teach Meson to recognize when a string path is the result of fetching a
dep.get_variable(), and special case this to be exempt from subproject
violations.
A requirement of this is that the file must be installed by
install_data() or install_subdir() because otherwise it is not actually
representative of what a pkg-config dependency would provide.
dep.get_variable() only supports string values for pkg-config and
config-tool, because those interfaces use text communication, and
internal variables (from declare_dependency) operate the same way.
CMake had an oddity, where get_variable doesn't document that it allows
list values but apparently it miiiiiight work? Actually getting that
kind of result would be dangerously inconsistent though. Also, CMake
does not support lists so it's a lie. Strings that are *treated* as
lists with `;` splitting don't count...
We could do two things here:
- raise an error
- treat it as a string and return a string
It's not clear what the use case of get_variable() on a maybe-list is,
and should probably be a hard error. But that's controversial, so
instead we just return the original `;`-delimited string. It is probably
the wrong thing, but users are welcome to cope with that somehow on
their own.
This has been broken ever since the original implementation. Due to a
typo, the optimization flag used a zero instead of an uppercase "o",
which the compiler then breaks on during argument parsing because it is
an invalid argument.
Fixes#10267
In print_options() k was a string instead of OptionKey, but
self.yielding_options expects OptionKey. Not sure how this has not been
catched by mypy.
Fix by keeping k as OptionKey which makes self.yielding_options useless.
Fixes: #9503
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 now has official guidance for the symlinked names of the tools, which
is great.
Qt now officially calls the tools `fooX` instead of `foo-qtX` where the
major version of Qt is X. Which is not great, because a bit of an
unofficial standard had prior art and now needs to change, and we never
adapted.
Prefer the official name whenever looking up qmake, and in the
testsuite, specifically look only for the official name on versions of
qt which we know should have that.
Fixes regression in commit c211fea513. The
original dependency lookup looked for `qmake-{self.name}`, i.e.
`qmake-qt5`, but when porting to config-tool, it got switched to
`qmake-{self.qtname}` i.e. `qmake-Qt6`, which was bogus and never
worked. As a result, if `qmake-qt5` and `qmake` both existed, and the
latter was NOT qt5, it would only try the less preferred name, and then
fail.
We need to define self.name early enough to define the configtool names,
which means we need to set it before running the configtool __init__()
even though configtool/pkgconfig would also set it to the same value.
Mark the tests as passing on two distros that were failing to detect
qmake due to this issue, and were marked for skipping because we assumed
that the CI skipping there was an expected case rather than an old
regression.
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>
Instead of reading intro-buildoptions.json, a giant json file containing
every option ever + its current value, use the private file that is
internally used by msetup for e.g. --wipe to restore settings.
This accurately tracks exactly the options specified on the command
line, and avoids lengthy summary messages containing all the overridden
defaults.
It also avoids passing potentially incompatible options, such as
explictly specifying -Dpython.install_env while also having a non-empty
-Dpython.{x}libdir
Fixes#10181
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.
msys/python in MSYS2 pretends to be cygwin in all cases for some time
now, so this check was impossible to hit.
The underlying confusion it tried to prevent is still there, namely trying
to build with mingw but wrongly using a msys/cygwin python/meson.
We can use the MSYSTEM env var to detect if we are in a mingw shell, and
in case the Python doesn't match we suggest installing mingw variants of both
python and meson.
Using msys/python + meson in a MSYS environment works fine on the other hand,
so no need to error out in that case.
Fixes#8726
Also addresses the concern raised in
https://github.com/mesonbuild/meson/issues/3653#issuecomment-474122564
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.
Forcing serialization on when writing out the build rule makes very
little sense. It was always "forced" on because we mandated a couple of
environment variables due to legacy reasons.
Add an attribute to RunTarget to say that a given target doesn't *need*
those environment variables, and let ninja optimize them away and run
the command directly if set.
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.
When something goes wrong with running the compiler in
_symbols_have_underscore_prefix_searchbin, print stderr instead,
as it actually contains helpful output while stdout is usually empty
in this case.
Fixes the following ResourceWarnings:
ResourceWarning: subprocess 25556 is still running
_warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
mesonbuild/compilers/mixins/gnu.py:195: ResourceWarning: unclosed file <_io.BufferedReader name=4>
return gnulike_default_include_dirs(tuple(self.exelist), self.language).copy()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Adds a new debug() function that can be used in the meson.build to
log messages to the meson-log.txt that will not be printed to stdout
when configuring the project.
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.
That method had nothing specific to the backend, it's purely a Target
method. This allows to cache the OptionOverrideProxy object on the
Target instance instead of creating a new one for each option lookup.
argparse is the gift that keeps on giving, hahaha. Suppress the script
argument when --version is specified to avoid "required argument not
provided" errors, and print the python version.
The version argument is required in order to make this baseline
functional as a resolved python for find_program, which may specify a
version and expect this to work with python itself. Our incomplete CLI
wrapper over the python CLI interface was missing this.
Fixes#10162
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
Fredrik Salomonsson
Sergey Fedorov
barracuda156
Daniel Mensinger
Eli Schwartz
Ben Brown
Xavier Claessens
John Lindgren
Matti Picus
Jussi Pakkanen
Eli Schwartz
Christoph Reiter
Marvin Scholz
Elliott Sales de Andrade
Tristan Partin
Jan Tojnar