I believe the intent (from 30d0c2292f) is
that `[binaries]` isn't needed just for "target-only cross" (build ==
host != target). This fixes the code to match that, hopefully clarifying
the control flow in the process, and also improves the message to make
that clear.
Use mesonlib.for_windows or mesonlib.for_cygwin instead of
reimplementing them.
Add CrossBuildInfo.get_host_system to shorten the repeated the code in
the mesonlib.for_<platform> methods.
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
Instead of exposing the endianness in the CPU family, canonicalise the CPU
family to just "ppc64" to match MIPS (which is also bi-endian).
Part of the work for #3842.
* environment: validate cpu_family in cross file
* run_unittests: add unittest to ensure CPU family list in docs and environment matches
* run_unittests: skip compiler options test if not in a git repository
* environment: validate the detected cpu_family
* docs: add 32-bit PowerPC and 32/64-bit MIPS to CPU Families table
Names gathered by booting Linux in Qemu and running:
$ python3
import platform; platform.machine()
Partial fix for #3751
This simplifies a lot of code, and centralize "key=value" parsing in a
single place.
Unknown command line options becomes an hard error instead of
merely printing warning message. It has been warning it would become an
hard error for a while now. This has exceptions though, any
unknown option starting with "<lang>_" or "b_" are ignored because they
depend on which languages gets added and which compiler gets selected.
Also any option for unknown subproject are ignored because they depend
on which subproject actually gets built.
Also write more command line parsing tests. "19 bad command line
options" is removed because bad cmd line option became hard error and
it's covered with new tests in "30 command line".
The 'Platform' envvar may not be set on Visual Studio 2008, at least
when using the SDK 7.0 compilers, so check the 'BUILD_PLAT' envvar so
that we do not mis-detect x64 build environments as x86.
This mistake seems to be a very common hiccup for people trying to use
Meson with MSYS2 on Windows from git or with pip.
msys/python uses POSIX paths with '/' as the root instead of a drive
like `C:/`, and also does not identify the platform as Windows.
This means that configure checks will be wrong, and many build tools
will be unable to parse the paths that are returned by functions in
Python such as shutil.which.
Closes https://github.com/mesonbuild/meson/issues/3653
Instead of using fragile guessing to figure out how to invoke meson,
set the value when meson is run. Also rework how we pass of
meson_script_launcher to regenchecker.py -- it wasn't even being used
With this change, we only need to guess the meson path when running
the tests, and in that case:
1. If MESON_EXE is set in the env, we know how to run meson
for project tests.
2. MESON_EXE is not set, which means we run the configure in-process
for project tests and need to guess what meson to run, so either
- meson.py is found next to run_tests.py, or
- meson, meson.py, or meson.exe is in PATH
Otherwise, you can invoke meson in the following ways:
1. meson is installed, and mesonbuild is available in PYTHONPATH:
- meson, meson.py, meson.exe from PATH
- python3 -m mesonbuild.mesonmain
- python3 /path/to/meson.py
- meson is a shell wrapper to meson.real
2. meson is not installed, and is run from git:
- Absolute path to meson.py
- Relative path to meson.py
- Symlink to meson.py
All these are tested in test_meson_commands.py, except meson.exe since
that involves building the meson msi and installing it.
In gcovr 3.1 the -r/--rootdir argument changed meaning causing
reports generated with gcovr 3.1 to not find the source files
and look for *.gcda in the whole source tree rather than the
build dir.
So, detect gcovr version and if 3.1 give build_root to -r instead
of source_root.
Fix exception handling of missing rustc, by making it look like the other
compiler detectors
Traceback (most recent call last):
File "/wip/meson/mesonbuild/environment.py", line 699, in detect_rust_compiler
p, out = Popen_safe(compiler + ['--version'])[0:2]
[...]
FileNotFoundError: [Errno 2] No such file or directory: 'rustc': 'rustc'
During handling of the above exception, another exception occurred:
[...]
File "/wip/meson/mesonbuild/environment.py", line 701, in detect_rust_compiler
popen_exceptions[compiler] = e
TypeError: unhashable type: 'list'
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
They now are published by the D Language Foundation, and not Digital
Mars. Therefore, their signature has changed slightly.
(We can not check for 'DMD', because that string appears in every
compiler version output to denote the frontend version used by the
compiler).
mohdamerkhalidi
Jussi Pakkanen
John Ericson
George Koehler
Nirbheek Chauhan
Khem Raj
Ross Burton
Vasu Penugonda
Ross Burton
Xavier Claessens
Chun-wei Fan
Niklas Claesson
makise-homura
Somasekhar Penugonda
Bedarkar, Malhar
Joel Klinghed
Hemmo Nieminen
Thibault Saunier
Jon Turney
Adam C. Foltzer
Aleksey Filippov
Edward Betts
Matthias Klumpp
Christoph Behle