Otherwise we get an error while checking the subproject version:
Uncomparable version string 'none'.
If the dependency was found as a not-found dependency in the
subproject and is not required, just take it.
Needs a `mock` kwarg to Interpreter to not do any parsing of build
files, but only setup the builtins and functions.
Also consolidate the documentation and data tests into one class.
The code was adding the library paths to LD_LIBRARY_PATH, but that
doesn't work on Windows where they need to be added to PATH instead.
Move the environ handling into gtkdoc_run_check() and add paths to PATH
instead of LD_LIBRARY_PATH when on Windows.
This fixes the gtk-doc build for glib on Windows
(in case glib isn't installed already)
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.
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.
Ninja buffers all commands and prints them only after they are
complete. Because of this, long-running commands such as `cargo
build` show no output at all and it's impossible to know if the
command is merely taking too long or is stuck somewhere.
To cater to such use-cases, Ninja has a 'pool' with depth 1 called
'console', and all processes in this pool have the following
properties:
1. stdout is connected to the program, so output can be seen in
real-time
2. The output of all other commands is buffered and displayed after
a command in this pool finishes running
3. Commands in this pool are executed serially (normal commands
continue to run in the background)
This feature is available since Ninja v1.5
https://ninja-build.org/manual.html#_the_literal_console_literal_pool
Meson tries to find the interpreter path through the "py" launcher on Windows in all
cases which breaks if meson is run under MSYS2 and an official CPython is installed as well.
MSYS2 Python doesn't install a py launcher which results in meson finding the system one instead
even though python2/python3 is in PATH.
Always check if the interpreter name is in PATH before falling back to checking the py launcher.
Meson already had code to propagate link dependencies from static
libraries to programs that use those static libraries.
Unfortunately, it was not handling the special cases of 'threads' and
'openmp' dependencies.