We test a couple ways of running the meson command, and double check
that the debug logs record the meson command used (including python).
But when running the meson command as an executable instead of as a
python script, we see whichever version `env` in the shebang sees.
Fix this by mocking the python command as well.
And don't run a pointless test to verify that the hardcoded list has
been manually maintained correctly. The same test rules used there can
translate directly to find_packages pattern rules.
Invoke create_zipapp.py from the root of the repository and it will
create a minimal zipapp with only the mesonbuild module code and a
__main__.py directly copied from meson.py
The meson.py launcher already tracks the desired entry point, and its
only other effect is to add the mesonbuild directory to the path if it
exists, which it won't in the zipapp. So there's no need to duplicate
this into another __main__.py
on some systems, tests may take over an hour to run--only to find
you might have used an unintended Meson version (e.g. release instead
of dev). This change prints the Meson version at the start of the
run_*tests*.py scripts.
Also, raise SystemExit(main()) is preferred in general over
sys.exit(main())
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
Since the last appveyor image update which also included a msys2 update
test_meson_installed() fails for the msys2 mingw jobs complaining that
the install path isn't included in PYTHONPATH.
It complains that "site-packages\" isn't included in "site-packages" ignoring
that the separator should be ignored here. Work around the issue by making
sure that the path set as PYTHONPATH always ends with os.sep.
samu prints a different message when the build is a no-op, so make
assertBuildIsNoop consider that as well.
Also, if compile_commands.json cannot be found, just skip the test. This
seems reasonable since meson just produces a warning if `ninja -t compdb`
fails.
Finally, only capture stdout in run_meson_command_tests.py, since the
backend may print messages the tests don't recognize to stderr.
Fixes#3405.
0a035de removed main from meson.py breaking the call from __main__.py.
This causes zipapps to fail, since the call to meson.main() fails.
Copying the invocation from meson.py fixes this issue.
Additionally, add a test to run_meson_command_tests.py that
builds a zipapp from the source and attempts executing this
zipapp with --help to ensure that the resulting zipapp is
properly executable.
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.
Eli Schwartz
Jussi Pakkanen
Daniel Mensinger
Dylan Baker
Michael Hirsch
Christoph Reiter
Michael Forney
Niklas Claesson
Nirbheek Chauhan
Christoph Burger-Scheidlin