| commit | fd309fff248bb697498befa89c3b81049b8b2c0c | [log] [tgz] |
|---|---|---|
| author | Simon McVittie <smcv@debian.org> | Wed Nov 20 08:00:20 2024 +0000 |
| committer | Jussi Pakkanen <jpakkane@gmail.com> | Fri Nov 29 14:43:22 2024 +0200 |
| tree | 0b7485bf4d038005a95124657524a3b3c363e860 | |
| parent | 467da051c859ba3112803b035e317bddadd756ef [diff] |
environment: Never require an exe_wrapper for native builds It is possible to run a container or chroot with one ABI on a CPU and kernel that would normally have a different ABI, most commonly by running a 32-bit container on a 64-bit CPU and kernel. When we do a native build in such an environment, the build and host architectures are both equal to the architecture of the container, and it is safe to assume that we can run executables from that architecture, because if we could not, we wouldn't be running Python successfully. Until now, we have been handling this by adding explicit special cases in `machine_info_can_run()` for each known-good combination of the detected CPU and the host architecture: every x86_64 can run x86 binaries, and every mips64 is assumed to be able to run 32-bit mips binaries. However, the equivalent would not be true on ARM systems: *most* aarch64 CPUs can run arm binaries, but not all (according to Wikipedia, ARM Cortex-A34 is an example of a purely 64-bit CPU that cannot execute 32-bit instructions). Instead, assume that if we are doing a native build (not a cross build), by definition we can run build-architecture executables, and since the host architecture is equal to the build architecture during a native build, this implies that we can run host-architecture executables too. This makes the behaviour of `need_exe_wrapper()` consistent with `meson.can_run_host_binaries()`, which in turn avoids `Compiler.run()` failing with error message "Can not run test applications in this cross environment" during native builds even though `meson.can_run_host_binaries()` has previously succeeded. Resolves: https://github.com/mesonbuild/meson/issues/13841 Signed-off-by: Simon McVittie <smcv@debian.org>
Latest Meson version supporting previous Python versions:
Meson is available on PyPi, so it can be installed with pip3 install meson. The exact command to type to install with pip can vary between systems, be sure to use the Python 3 version of pip.
If you wish you can install it locally with the standard Python command:
python3 -m pip install meson
For builds using Ninja, Ninja can be downloaded directly from Ninja GitHub release page or via PyPi
python3 -m pip install ninja
More on Installing Meson build can be found at the getting meson page.
Meson can be run as a Python zip app. To generate the executable run the following command:
./packaging/create_zipapp.py --outfile meson.pyz --interpreter '/usr/bin/env python3' <source checkout>
Meson requires that you have a source directory and a build directory and that these two are different. In your source root must exist a file called meson.build. To generate the build system run this command:
meson setup <source directory> <build directory>
Depending on how you obtained Meson the command might also be called meson.py instead of plain meson. In the rest of this document we are going to use the latter form.
You can omit either of the two directories, and Meson will substitute the current directory and autodetect what you mean. This allows you to do things like this:
cd <source root> meson setup builddir
To compile, cd into your build directory and type ninja. To run unit tests, type ninja test.
More on running Meson build system commands can be found at the running meson page or by typing meson --help.
We love code contributions. See the contribution page on the website for details.
The channel to use is #mesonbuild either via Matrix (web interface) or OFTC IRC.
More information about the Meson build system can be found at the project's home page.
Meson is a registered trademark of Jussi Pakkanen.