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
Start the process by traversing the tree and adding the S_IWRITE and
S_IREAD bits to the file's mode (which are also preserved on Windows.)
This fixes windows_proof_rmtree's inability to remove read-only files,
which was uncovered in testing the new `install_mode` feature.
Tested: ./run_tests.py passes on Linux, appveyor CI on Windows passes.
This makes it possible to customize permissions of all installable
targets, such as executable(), libraries, man pages, header files and
custom or generated targets.
This is useful, for instance, to install setuid/setgid binaries, which
was hard to accomplish without access to this attribute.
Expose depend_files: from the custom_target this creates.
This is the change suggested in #2815, with tests and documentation added.
Fixes#2789 (duplicate #2830)
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.
Currently, commandrunner breaks when we give options to python because
it assumes python commands are in the form "python script.py", rather
than "python -u script.py" or "python -u -m module script.py". Extend it
to be more resilient and correctly parse python options.
Currently, ExternalProgram get_path() assumes the last component in the
path is always the actual command path. However, this is not always
right. For example, in the command "python -u", we should return
"python" and not "-u". However, in other cases, like "python script.py",
then the last component is the right one.
The heuristic that seems to capture this is to use the last argument
that is still a file. This means options get ignored, but "python
script.py" still works. Let's use this heuristic, at least for now.
This checks not only for existence, but also for usability of the
header, which means it does a full compilation and not just
pre-processing or __has_include.
Fixes https://github.com/mesonbuild/meson/issues/2246
Simplify support for alternate bases using int(..., base=0) which
auto-detects it using the standard Python syntax for numbers.
Octal numbers are useful to specify permission bits and umasks.
Binary numbers are not super useful... But considering we get them for
free, let's allow them here too.
v2: Tweak the regex so it doesn't accept a decimal number with a leading
zero, which is invalid for int(..., base=0) and would raise a ValueError
if passed around.
Nirbheek Chauhan