Also forcibly undefine __has_include and test that the fallback include
check in cc.has_header() works.
This is important because all the latest compilers support it now
and we might have no test coverage at all by accident. GCC 5, ICC 17,
Clang 3.8, and VS2015 Update 2 already support it.
We automatically convert that to use sys.executable now which is
always available on all platforms (because we're running with it).
On some platforms like NetBSD, `python` doesn't exist, and you must
use a specific python version. On most other distros, `python` is
Python 2, and we don't want to depend on that.
Closes https://github.com/mesonbuild/meson/issues/695
All these scripts were being used as `find_program()`, so we do not
lose any test coverage by doing this.
There is no way for us to know that 'source.c' is a file in the source
tree if it's a string. It needs to be a file object.
This used to work earlier because we used to incorrectly run the
configure_file() command in the source dir (!) instead of the build
dir. This had nasty side-effects such as creating files in the source
tree unless you specified an absolute path...
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.
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.
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.
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
At the same time, also fix the order in which compile arguments are
added. Detailed comments have been added concerning the priority and
order of the arguments.
Also adds a unit test and an integration test for the same.
Also add a test() that can be run on all platforms.
Currently unit tests are only run on Linux, so this was only testing the
Ninja backend. This change reveals that build-by-default was broken with
the Visual Studio backend.
Use a single check for both cases when we have includes and when we
don't. This way we ensure three things:
1. Built-in checks are 100% reliable with clang and on macOS since clang
implements __has_builtin
2. When the #include is present, this ensures that __builtin_func is not
checked for (because of MSYS, and because it is faster)
3. We fallback to checking __builtin_func when all else fails
Our "43 has function" test should also work with clang and icc on Linux,
so enable them. Also detect builtins with __has_builtin if available,
which is much faster on clang.
There is a feature request for the same with GCC too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
With the 'install_mode' kwarg, you can now specify the file and
directory permissions and the owner and the group to be used while
installing. You can pass either:
* A single string specifying just the permissions
* A list of strings with:
- The first argument a string of permissions
- The second argument a string specifying the owner or
an int specifying the uid
- The third argument a string specifying the group or
an int specifying the gid
Specifying `false` as any of the arguments skips setting that one.
The format of the permissions kwarg is the same as the symbolic
notation used by ls -l with the first character that specifies 'd',
'-', 'c', etc for the file type omitted since that is always obvious
from the context.
Includes unit tests for the same. Sadly these only run on Linux right
now, but we want them to run on all platforms. We do set the mode in the
integration tests for all platforms but we don't check if they were
actually set correctly.
Compiler versions 15.0 and later actually ignore invalid values for the
-std= option unless `-diag-error 10159` is passed, so we need to put
that in the unit test.
I have tested this with versions 14.0.3, 15.0.6, 16.0.4, and 17.0.1.
Would be great if someone could test with 13.x.y
Cache the absolute dir that the script is searched in and the name of
the script. These are the only two things that change.
Update the test to test for both #1235 and the case when a script of the
same name is in a different directory (which also covers the subproject
case).
Closes#1235
This is useful in many cases where the list of files cannot be known in
advance and is just dumped inside a directory. For example when
generating documentation with doxygen and other tools that we don't have
built-in support for.
Includes a test for the same.
Closes#893
Nicolas Schneider
Nirbheek Chauhan
Haakon Sporsheim
Mike Sinkovsky
Tim-Philipp Müller
Jussi Pakkanen
Elliott Sales de Andrade
Igor Gnatenko