Add a cross-file for MSVC UWP ARM64.
Bump cidata tag to get an updated install.ps1 script (run by run.ps1)
which sets the vcvars environment correctly when cross-compiling.
Since arranging the correct environment for simultaneous cross and
native 'cl' use is hard, this is test run uses '--cross-only' so we
don't require a native compiler.
Extend '--cross-only' so it also explicitly uses a machine file which
makes all build machine compilers unusable.
Add '--cross-only' option to run_tests.py, so we can arrange not to run
tests in the 'native' suite when only a cross-compiler is available, as
they can't succeed.
Split out tests (and parts of tests) which require a native compiler
from the 'common' suite to a new suite called 'native', so we can
selectively avoid running those tests when only a cross-compiler is
available.
Also move test '211 cmake module' to 'cmake' suite, since it appears
that the way we use cmake requires a native compiler.
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
There are cases when it is useful to wrap the main meson executable with
a script that sets up environment variables, passes --cross-file, etc.
For example, in a Yocto SDK, we need to point to the right meson.cross
so that everything "just works", and we need to alter CC, CXX, etc. In
such cases, it can happen that the "meson" found in the path is actually
a wrapper script that invokes the real meson, which may be in another
location (e.g. "meson.real" or similar).
Currently, in such a situation, meson gets confused because it tries to
invoke itself using the "meson" executable (which points to the wrapper
script) instead of the actual meson (which may be called "meson.real" or
similar). In fact, the wrapper script is not necessarily even Python, so
the whole thing fails.
Fix this by using Python imports to directly find mesonmain.py instead
of trying to detect it heuristically. In addition to fixing the wrapper
issue, this should make the detection logic much more robust.
Also sets more groundwork for running unit tests with backends other
that Ninja.
Transferring global state to executors is totally broken in Python 3.4
so just serialize all the commands.