Otherwise Python gets all confused and it makes testing difficult.
Also minimally emulate the behaviour of the normal object to make the rest
of the code happy.
This adds a hidden option to dump the current otherwise hidden peristant
state in coredata.dat.
This interface is unstable as meson has no compatibility promises about
coredata.dat.
This has the adventage that "meson --help" shows a list of all commands,
making them discoverable. This also reduce the manual parsing of
arguments to the strict minimum needed for backward compatibility.
This is a regression in Meson 0.48.0, commit 674ae46, Meson used to
exit(0) when running setup command in a builddir already configured.
Changing to exit(1) breaks some build tools that does "meson builddir
&& ninja -C builddir".
Closes#4247.
Allows to manually reconfigure a project the same way backends would do
(e.g. ninja reconfigure). This has the advantage that new options can be
set using "meson --reconfigure -Dfoo=bar" and solve situations where a
project cannot be reconfigured because new options has been added with
the wrong default value.
Fixes#3543.
This makes any warning message printed by meson raise an exception,
intended to be used by CI and developpers to easily catch deprecation
warnings and other potential issues.
If only 1 dir is provided, the 2nd defaults to '.' and if none is
provided they default to '.' and '..'. It should be builddir first,
followed by sourcedir, but validate_core_dirs() will still swap them if
builddir contains a meson.build file.
All options are now the projectoptions list, regardless of how they got
defined in the command line.
This also delays setting builtin option values until the main project()
default options are parsed to simplify the code. This is possible
because we already delayed setting the backend after parsing main
project() in a previous commit.
The project() function could have a different value for the backend
option in its default_options kwargs.
Also set backend options, passing them in command line had no effect
previously.
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.
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.
Outputs two profile logs: one for the interpreter run and another for
the backend-specific build file generation. Both are stored in
meson-private in the build directory.
Currently meson only accepts `-Dopt=value` for builtin options when
calling `meson configure` and `--opt=value` for builtin options when
calling `meson` initially. This is a confusing behavior, and users only
get a small warning at the top of a potentially long configuration
summary to catch this.
This has confused end users and developers alike, there are at least 5
duplicates of the bug this fixes, and I have personally been asked about
this more times than I can count. The help documentation doesn't make
it clear that -D cannot be used to set options like prefix and bindir.
This adds support for -D options to the initial meson call, but not --
options to the meson configure call. I think it's better to have one way
to do things, and -- options are kinda one off while -D is used
everywhere else, so lets stick with that.
Related #969
We have all the information needed to calculate the builtin arguments in
the coredata module already, don't duplicate that in the mesonmain
module as well.
Currently we manually pass the argparse action, this isn't very DRY,
since the builtin_types already has all the data necessary to find that.
This adds a new function to determine the action based on the default
type.
Michael Hirsch, Ph.D