We can't support generated XML files with custom_target() because the
dependency scanning happens at configure time, but we *can* support
generating them with configure_file().
Closes https://github.com/mesonbuild/meson/issues/1380
The same substitutions and rules as custom_target().
Also generally fix it to actually work when run in a subdir and with
anything other than absolute paths for input and output files.
We now also log a message when configuring files.
Includes tests for all this.
This means replacing @PLAINNAME@ and @BASENAME@ in the outputs. This is
the same feature as generator().
This is only allowed when there is only one input file for obvious
reasons + failing test for this.
Factor it out into a function in mesonlib.py. This will allow us to
reuse it for generators and for configure_file(). The latter doesn't
implement this at all right now.
Also includes unit tests.
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.
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
It's only useful to use those when you have to override include dirs
or library paths by appending them from various sources according to
the priority order, or if the compiler args need to be converted from
Unix/GCC-style to native (MSVC, for instance) style.
Sanity checks match neither of these.
Closes https://github.com/mesonbuild/meson/issues/1351
To reproduce, one could write:
foo = files('foo.c')
foo[0].path()
and get:
Traceback (most recent call last):
[snip]
File "/home/trhd/Projects/meson/mesonbuild/interpreterbase.py", line 398, in method_call
raise InvalidArguments('Variable "%s" is not callable.' % object_name)
UnboundLocalError: local variable 'object_name' referenced before assignment
Fix this by handling file objects separately.
os.path.commonpath was added in Python 3.5, so just write our own for
now. pathlib was added in Python 3.4, so this should be ok. We need to
use that instead of doing str.split() etc because Windows path handling
has a lot of exceptions and pathlib handles all that for us.
Also adds a unit test for this.
Also, now the linker options are added from various sources in the same
order as compiler arguments for compile commands. As a result, all
libraries and library paths from external and internal sources are added
after all the linker options have been added.
As a result option_link_args() are added when libraries are added to the
list since currently the only thing they add are the libraries specific
in cpp_winlibs/c_winlibs. This fixes an issue where compilation with the
MinGW toolchain (which uses static libraries for winlibs) would result
in undefined symbol errors because the static libraries would be added
in the very beginning and hence would not be scanned for symbols.
Detailed comments have been added that explain where each option is
coming from and why it's been added at that specific point.
More improvements are necessary here because we currently still
unnecessarily repeat libraries from dependencies over and over, which
is a major problem in gst-build because inter-subproject dependencies
cause linker command-lines to almost exceed the argument list length
limit imposed by the kernel. It is also causing us to unnecessarily
add static libraries which have already been linked into a shared
library. See: self.build_target_link_arguments()
Nirbheek Chauhan
Jussi Pakkanen
Hemmo Nieminen
Thibault Saunier
Dima Krasner
Matthieu Gautier
Mike Sinkovsky