We don't need dependencies to work correctly to use the output of
configure_file in the dependencies: kwarg.
This allows GNOME Recipes to built without the latest glib git.
Ever since we changed how we do library searching, the full path to the
library has not been available under `.fullpath`. This has been broken
for at least a year...
And actually test that prog.path() works. The earlier test was just
running the command without checking if it succeeded.
Also make everything use prog.get_command() or get_path() instead of
accessing the internal member prog.fullpath directly.
We also need to check whether the program found in PATH can be executed
directly by Windows or if we need to figure out what the interpreter is
and add it to the list.
Also add `msc` to the list of extensions that can be executed natively
Includes a project test and a unit test for this and all expected
behaviours on Windows.
Without this, we can output a mixture of '/' and '\' on platforms where
os.path.sep is '\' and prefix or outdir uses '/'. Let's always return
the path in the format of the platform we're running on.
This is needed to make the test_install_introspection() unittest work
properly on Windows.
On macOS, the temporary directory is inside /var/folders, but /var is
a symlink to /private/var, and for some reason that messes up path
traversal when you're inside the temporary directory and the source
directory is never found, and ninja runs in a loop trying to
regenerate files that can never be regenerated.
Otherwise if the list of sources changes on reconfigure after building,
the static library will contain both the old and new objects.
Closes https://github.com/mesonbuild/meson/issues/1355
Without this, files() in the arguments give an error because it's a list
of mesonlib.File objects:
Array as argument 1 contains a non-string.
It also breaks in nested lists. Includes a test for this.
- Hanlde correctly a multi command string in evironment variable, e.g.:
CC="ccache gcc" meson
- Handle correctly a list for the cross-file option, e.g:
[binaries]
c = ['ccache', '/usr/local/bin/mips-linuc-gcc']
This commit fixes#1392.
os.path.commonpath (and our implementation of it) both always return the
path using the native operating system path separator, so we can't just
directly compare it since the prefix could be specified in '/', and
commonpath would use '\' on Windows.
Also add a unit test for this.
A user may want to add libraries to link with in the (c|cpp)_link_args
property of the cross-compile file.
Those libraries should be at the end of the command line due to reference
resolution mechanism of the compiler.
By moving the cross_args after LINK_ARGS we are sure that specific
cross-compilation libraries are at the end of the command line.
See [github PR #1363](https://github.com/mesonbuild/meson/pull/1363) to
have the context of this change.
On some distros, running this causes Python to find the file itself as
the implementation of the `copy` module:
$ python3 copy.py
Traceback (most recent call last):
File "copy.py", line 4, in <module>
import shutil
File "/usr/lib/python3.4/shutil.py", line 14, in <module>
import tarfile
File "/usr/lib/python3.4/tarfile.py", line 48, in <module>
import copy
File "/c/Users/nirbheek/projects/meson.git/test cases/common/134 generated llvm ir/copy.py", line 6, in <module>
shutil.copyfile(sys.argv[1], sys.argv[2])
AttributeError: 'module' object has no attribute 'copyfile'
because down the import dependency chain of copy.py the 'tarfile' module
was trying to import the 'copy' standard library module but was finding
the copy.py file first because it was in the current directory.
Closes https://github.com/mesonbuild/meson/issues/1359