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.
The setup's timeout multiplier will always be set, and it will default
to 1.0, so just use that.
Without this, the setup's timeout multiplier was always ignored.
When using a setup, use the setup name as the namebase for the logfile
instead of the wrapper. The wrapper may not be set, or it may be shared
between test setups.
Also don't try to use the wrapper if it's an empty list.
Closes https://github.com/mesonbuild/meson/issues/1371
Otherwise env is {} and we get a traceback trying to use the setup:
$ /home/cassidy/dev/meson/mesontest.py -C build --setup valgrind
ninja: Entering directory `/home/cassidy/dev/gst/master/gst-build/build'
ninja: no work to do.
Traceback (most recent call last):
File "/home/cassidy/dev/meson/mesontest.py", line 579, in <module>
sys.exit(run(sys.argv[1:]))
File "/home/cassidy/dev/meson/mesontest.py", line 575, in run
return th.doit()
File "/home/cassidy/dev/meson/mesontest.py", line 337, in doit
self.run_tests(tests)
File "/home/cassidy/dev/meson/mesontest.py", line 485, in run_tests
self.drain_futures(futures, logfile, jsonlogfile)
File "/home/cassidy/dev/meson/mesontest.py", line 504, in drain_futures
self.print_stats(numlen, tests, name, result.result(), i, logfile, jsonlogfile)
File "/usr/lib64/python3.5/concurrent/futures/_base.py", line 398, in result
return self.__get_result()
File "/usr/lib64/python3.5/concurrent/futures/_base.py", line 357, in __get_result
raise self._exception
File "/usr/lib64/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/cassidy/dev/meson/mesontest.py", line 216, in run_single_test
child_env.update(self.options.global_env.get_env(child_env))
AttributeError: 'dict' object has no attribute 'get_env'
There is no harm in doing this, and this is the simplest fix for this.
Closes https://github.com/mesonbuild/meson/issues/1371
The output is very confusing otherwise. Before it said
'No suitable tests defined' and then showed a list of tests that
passed/failed.
Now it will just say 'No suitable tests defined' and exit.
This is useful enough that we can enable this for everyone. If people
really don't want this, they can pass MALLOC_PERTURB_=0 in the
environment or in the test.
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.
Nirbheek Chauhan