Currently you can only use one of qt4, qt5, qt6 in a single project
when using a machine file because the config-tool lookup for qt only
looks at `qmake` in the machine files, instead of looking up the
binary names directly.
Allow specifying `qmake` `qmake4` `qmake5` and `qmake6`.
This is necessary for gstreamer, which can build separate qt5 and qt6
plugins that are distributed as static libraries, so the user can pick
which one to use.
The library names are directly mapped to filenames by meson while the
crate name gets spaces/dashes replaced by underscores. This works fine
to a certain degree except that rustc expects a certain filename scheme
for rlibs that matches the crate name.
When using such a library as a dependency of a dependency compilation
will fail with a confusing error message.
See https://github.com/rust-lang/rust/issues/110460
The paths in meson.build use / as path separator, however, the paths
constructed during the directory structure walk use native path
separators, thus the path never compare equal to the excluded ones.
Normalize the exclusion paths before the comparison.
By default clippy-driver will report its own version, which is not very
useful to check the toolchain version. Instead make sure to extract the
actual toolchain version here.
Rust doesn't have a concept of dependency compile arguments, i.e.
something like headers. Dependencies are linked in and all required
metadata is provided by the linker flags.
CPython adds a hard to avoid hardcoded link flag to look for a debug
libpython. This results in a very puzzling error, so emit a warning
with a clear message. Note that pybind11 has a workaround for this,
which undefines `_DEBUG`. So users who use only pybind11 can use
non-release buildtypes, but they won't get debug symbols on Windows
unless they have a debug build.
This matches the tests for Python extensions.
Also include some other cleanups to these `meson.build` files:
Adding `python_dep` is no longer needed, this is automatic now.
Use a single line for `import('python').find_installation()`,
because the result of `import('python')` by itself is not used
for anything.
In commit 808d5934dd, compiler.sizeof was
refactored to introduce caching, but cmake subprojects did not adapt to
that API change and ended up embedding the python repr of a tuple as a
cmake variable.
patch on Windows is provided by MSYS, which only understands POSIX
paths, with `/`. Using Windows paths with `\` results in a "file not
found" error.
We got a little lucky here because the path is relative, so the drive
letter difference doesn't affect us.
import('python').find_installation('python').version() causes exception
because of a missing initialization, when `find_installation()` receives
a name or a path.
Checking the executable basename sort of works, at least for Windows,
since Windows always happens to use exactly this approach. However, the
official pyinstaller documentation suggests a very different approach:
https://pyinstaller.org/en/stable/runtime-information.html
This approach is more robust since it works on any OS, and in particular
it allows me to test the PyInstaller bundle functionality on Linux, even
though we don't officially distribute it as such.
pyinstaller considers .py files to not be data by default. The entire
architecture of pyinstaller is, in fact, different from zipapp or
unpacked modules -- because it actually has to use a resource loader
with on-disk files *separate* from the module itself. So just because a
file gets packaged in the application does not mean it's usable as an
importlib.resources compatible resource.
Although we collect data files in general, we need to make sure that .py
files are collected from scripts, because we may try to run them
standalone from an external process.
Fixes#11689
Running some container-like mechanisms such as chroot(1) from sudo, can
result in a new isolated environment where the environment variables
exist but no users exist. From there, a build is performed as root but
installation fails when we try to look up the passwd database entry for
the user outside of the chroot.
Proper container mechanisms such as systemd-nspawn, and even improper
ones like docker, sanitize this and ensure those stale environment
variables don't exist anymore. But chroot is very low-level.
Avoid crashing when this happens.
Fixes#11662
A user might run `sudo somewrapper` to build and install something with
meson, and it is not actually possible to drop privileges and build,
since the build directory is also owned by root.
A common case of this is `sudo pip install` for projects using
meson-python or other python build-backends that wrap around meson.
Fixes#11665
* --load-average
* --gdb-path
* description for install
Found by https://www.check-spelling.dev/
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
During evaluation of codeblocks, we start off with an iteration of
nodes, and then while evaluating them we may update the global
self.current_node context. When catching and formatting errors, we
didn't take into account that the node might be updated from the
original top-level iteration.
Switch to formatting errors using self.current_node instead, to ensure
we can point at the likely most-accurate actual cause of an error.
Also update the current node in a few more places, so that function
calls always see the function call as the current node, even if the most
recently parsed node was an argument to the function call.
Fixes#11643
Nirbheek Chauhan
Eli Schwartz
Sebastian Dröge
Daniele Nicolodi
Volker Weißmann
Radek Bartoň
Ralf Gommers
MaxHearnden
Peter Hull
Jakob Widauer
L. E. Segovia
Charles Brunet
Jussi Pakkanen
Josh Soref
Christoph Reiter