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.
It is nicer to early raise exception if the value from meson_options.txt
is not a string in "[]" format than duplicating the parser code for both
cases.
Also it was checking for duplicated items only in the user_input case,
but we should also check for dups in the default value from
meson_options.txt.
The 'Platform' envvar may not be set on Visual Studio 2008, at least
when using the SDK 7.0 compilers, so check the 'BUILD_PLAT' envvar so
that we do not mis-detect x64 build environments as x86.
This reverts commit 0045d95a16.
<jeandet> nirbheek, it seems 0045d95a16 is
really wrong, I've tested on Ubuntu. While writing this line I was
thinking that you can't have Qt without a working qmake in the path. On
Ubuntu you have that qtchooser stuff which is misleading.
Normally, people would just pass -fembed-bitcode in CFLAGS, but this
conflicts with -Wl,-dead_strip_dylibs and -bundle, so we need it as
an option so that those can be quietly disabled.
Traceback (most recent call last):
File "meson.py", line 29, in <module>
sys.exit(mesonmain.main())
File "mesonbuild/mesonmain.py", line 411, in main
return run(sys.argv[1:], launcher)
File "mesonbuild/mesonmain.py", line 320, in run
return mintro.run(remaining_args)
File "mesonbuild/mintro.py", line 234, in run
list_installed(installdata)
File "mesonbuild/mintro.py", line 72, in list_installed
for path, installdir, aliases, unknown1, unknown2 in installdata.targets:
ValueError: too many values to unpack (expected 5)
When the exe runner is `wine` or `wine32` or `wine64`, etc.
This allows people to run tests with wine.
Note that you also have to set WINEPATH to point to your custom
prefix(es) if your tests use external dependencies.
Closes https://github.com/mesonbuild/meson/issues/3620
When using binutils's windres, we can instruct it to invoke the preprocessor
in such a way that it writes a depfile, so that dependencies on #included
files are automatically tracked.
Not implemented for MSVC tools, so skip testing it in that case.
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.)