This would make it harder to parse an option to mesonconf such
as -Dfoo:bar:baz:fun=value since it could mean either of these:
* For subproject 'foo:bar:baz', set the option 'fun' to 'value'
* For subproject 'foo:bar', an invalid option 'baz:fun' was set
To differentiate between these two we'd need to create the list of
subprojects first and then parse their options later, which
complicates the parsing quite a bit.
The configure_file command raised an exception when an input was specified as a
File, because os.path.join does not take File objects directly. This patch
converts a File object to a string and adjusts the subsequent os.path.join
calls.
In this case, the arguments to MinGW windres will contain spaces and
the test will definitely fail, so just skip it.
This effectively means that manually running the test will be fine, but
running it via run_project_tests.py will always fail (skip).
Now as long as you have a C compiler available in the project, it will
be used to compile assembly even if the target contains a C++ compiler
and even if the target contains only assembly and C++ sources.
Earlier, the order in which sources appeared in a target would decide
which compiler would be used.
However, if the project only provides a C++ compiler, that will be
used for compiling assembly sources.
If this breaks your use-case, please tell us.
Includes a test that ensures that all of the above is adhered to.
The paths are already relative to the target dir.
Includes a test for this which generates and builds in subdirs. If all
the generation and usage is done in the build root, this bug will
obviously not be triggered.
An empty / no-op dependency can be expressed as []. This works with
the dependencies kwarg in executable targets such as shared_library,
but now with declare_dependency, where it would error out with
"error: Dependencies must be external deps" because the deps are
not flattened in this case. This patch fixes that.
Fixes#1500
Besides fixing output capture, it also fixes a strange bug in MSBuild
where if the command list is too long, it will remove random
characters from the command list before passing it to the command.
Closes https://github.com/mesonbuild/meson/issues/1417
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 differ from cmake in the following manner:
* We only set the major version (SOVERSION) in the dylib
* If SOVERSION is not specified, we deduce it from version (VERSION)
See installed_files.txt for a list of output dylib names.
In this test, we try to manually link against the generated library to
create an executable and then run it to verify that it works.
Also test for all possible library versioning in the versioning tests on
Windows. Even though they yield the same dll naming, we should still
test 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.
The GNUstep runtime shipped in Linux distros is GCC-specific and won't
work with clang. You have to build it separately and set the paths
yourself.
In file included from /root/b 05ywf6dg/stringprog@exe/stringprog-unity.m:1:
In file included from /root/b 05ywf6dg/../test cases/objc/2 nsstring/stringprog.m:1:
In file included from /usr/include/GNUstep/Foundation/NSString.h:89:
In file included from /usr/include/GNUstep/Foundation/NSObject.h:30:
In file included from /usr/include/GNUstep/Foundation/NSObjCRuntime.h:213:
/usr/include/GNUstep/GNUstepBase/GSObjCRuntime.h:58:11: fatal error: 'objc/objc.h' file not found
#include <objc/objc.h>
^
On my system, I get the same error and the objc.h path is:
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/include/objc/objc.h
https://github.com/mesonbuild/meson/pull/1406 had an incomplete fix
for this. The test case caught it.
Note: this still doesn't test that setting it in the cross-info works,
but it's the same codepath as via the environment so it should be ok.
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...
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.
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.
Nirbheek Chauhan
Philipp Ittershagen
Jussi Pakkanen
Patrick Griffis
Tim-Philipp Müller
Nicolas Schneider
Nicolas Schneider
Haakon Sporsheim