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
Running pyinstaller to create a bundle, and using the resulting
`pyinst-tmp/meson/meson setup ...` with the cmake module revealed that
no data files were being bundled, unlike what we did for setup.cfg. Fix
this oversight.
Fixes#10163
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.
We expose a reason after the string 'MESON_SKIP_TEST', but it is
actually ignored when running the test, so it is only useful as
documentation and really might as well be a comment.
Make it even more useful by actually printing that string after the
'[SKIPPED]' message.
Also, sometimes a test can be skipped for multiple reasons, and it would
be useful to know which one occurred.
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
It isn't possible to have one target depend on a run_target, because
those produce no outputs and are always out of date. But the docs didn't
specify which types of target are valid here.
Correct the docs to align with the implementation.
Fixes#10198
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.
Tests the two new detection methods for the underscore prefix
against what is detected in the binary. Contrary to the in-the-wild
failures, we can trust the binary here as we do not get any additional
flags that influence the binary contents in this test environment.
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.
Make use of pyinstaller hooks by creating a hook that updates how the
`mesonbuild` import functions.
This is more or less the same as passing a bajillion arguments to
pyinstaller's CLI, but allows the logic to be self-contained (and
reusable). It becomes more obvious what parts of the process pertain to
pyinstaller, and which parts pertain to MSI/pkg creation.
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.
John Lindgren
Daniel Mensinger
alex-tee
mattip
Eli Schwartz
Jussi Pakkanen
Eli Schwartz
Xavier Claessens
John Ericson
Christoph Reiter
Marvin Scholz
Elliott Sales de Andrade
Tristan Partin
Jan Tojnar