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 check for the existence of PDB files in the install script, so we
don't need to do all this mucking about here. That's more robust too
because we don't need to parse build arguments in buildtype=plain
and decide if the PDB file would be generated.
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 need to do obj.get_command() and in fact it's wrong
because the VS backends need to resolve each object to absolute paths
and get_command() does not do that.
This should fix invocation of GNOME module helpers with the VS backends
For the record, absolute paths for programs are needed because the
same PATH environment won't necessarily be available to Visual Studio
when it builds the generated solution.
Related to https://github.com/mesonbuild/meson/issues/1419
This used to produce a warning, but then would crash anyway. It's
simpler if we just error out and have the user disable gir generation or
install gobject-introspection.
This is especially useful with the glib testing framework where you
can select which tests to run within a single test executable by
pasing `-p /some/test/path`
It would add --args to `wrap` repeatedly for each re-run, resulting in
gdb erroring out with `--args: No such file or directory.`
Also don't make --gdb and --wrapper mutually exclusive. Sometimes people
want to run under a wrapper *and* run it under gdb.
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
These compilers are available in MinGW and can be built on macOS.
More interestingly, `gcc` is a wrapper around `clang` on macOS, so we
will detect the compiler type incorrectly on macOS without this.
If you pass options, the last element in the array won't be the
compiler basename, so just check if the basename is in the exelist
somewhere.
Includes a test.
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.
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.
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.
Nirbheek Chauhan
Jussi Pakkanen
Patrick Griffis
Marc Becker
Elliott Sales de Andrade
Fabio Porcedda
Hase Bastian
Rodrigo Lourenço