Since f3ff8fe6 (0.39.0), this has a common implementation with the same
substitution in generators, but I think they existed earlier.
@BASENAME@ is used internally by the custom target generated by
windows.compile_resources()
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
This new unit test will use the targets in '198 install_mode' and
confirm that every file and directory gets the expected mode, ensuring
that the setting is properly applied at install time.
This is a simple test case, checking for installed_files.txt, which just
makes sure the syntax is accepted.
Manual tests confirmed the permissions were set correctly.
A follow up commit adds a unit test based on this directory.
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.
When using an install_mode in install_subdir(), that should apply to the
files and not to the directory tree.
Otherwise, an install_mode not including the executable bit will make
the tree inaccessible, since directories need it to be traversed.
If the mode needs to be applied to both files and directories, then
install_subdir() is only useful to install files with the executable bit
set, which is not really that useful...
So default to just using the umask for the directories and applying
install_mode to the files only.
This can be reviewed in the future, possibly by adding a separate
install_dir_mode attribute, or perhaps adding an optional fourth field
to FileMode with the mode for directories (this is similar to how RPM
handles specifying mode of directory trees recursively added to the
package.)
For the VS backend, assertRebuiltTarget() asserts the that target is both
recompiled and relinked. This isn't correct for test_rc_depends_files, as
changing the rc script's dependencies only causes the executable to be
relinked, and not to also have it's source recompiled.
assertRebuiltTarget already gets this right for the ninja backend.
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.
* docs/reference-manual: link to references tables
Currently the reference manual entries for *machine.cpu_family() and
*machine.system() have incomplete (and wrong) information. Rather than
continue to duplicate this information just link to the reference
tables.
* docs/Reference-manual: fix link target
The IDs in hotdoc are always lowered, so this pointed to the right page,
but didn't go to the heading.
* docs/Reference-manual: link compiler.get_id directly to tables
Currently it goes round about to an entry that doesn't add much
information and points to the reference table. Instead just point to the
reference table.
Mention that the dependency name will also be searched for as a framework on
OSX.
Note that additional dependency-specific keywords may be used by custom
dependency lookup.
PR #1852 only adds mention of this to the release note.
I think it's useful to have a list of all dependency names which are treated
specifically in Dependency.md, so add 'thread' and 'openmp'.
Jon Turney
Nirbheek Chauhan
Marvin Scholz
Mathieu Duponchelle
Filipe Brandenburger
Jussi Pakkanen
Mathieu Duponchelle
Dylan Baker
Salamandar