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
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.
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.
- Hanlde correctly a multi command string in evironment variable, e.g.:
CC="ccache gcc" meson
- Handle correctly a list for the cross-file option, e.g:
[binaries]
c = ['ccache', '/usr/local/bin/mips-linuc-gcc']
This commit fixes#1392.
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.
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()
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.
While reading shebangs, when we detect an attempt to run 'python3', use
sys.executable instead. For example:
#!/usr/bin/python3
#!python3
#!/usr/bin/env python3
Back in November when this broke, we didn't notice because our tests
are run in-process, so we don't check that `msbuild RUN_TESTS.vcxproj`
and `ninja test` actually work.
Now we do.
Always generate the vcxproj file, but only add it to the build
configuration if it's either supposed to be built by default, or is
a dependency of another target that is built by default.
Previously, build_by_default=false targets would not be built at all
even if they were used in a test (as the exe or as a command-line
argument) which would lead to a test failure.
Now we look into all the defined tests and add all CustomTargets and
BuildTargets used in them to the list of build_by_default targets.
The purpose of this class is to make it possible to sanely generate
compiler command-lines by ensuring that new arguments appended or added
to a list of arguments properly override previous arguments.
For instance:
>>> a = CompilerArgs(['-Lfoo', '-DBAR'])
>>> a += ['-Lgah', '-DTAZ']
>>> print(a)
['-Lgah', '-Lfoo', '-DBAR', '-DTAZ']
Arguments will be de-duped if it is safe to do so. Currently, this is
only done for -I and -L arguments (previous occurances are removed when
a new one is added) and arguments that once added cannot be overriden
such as -pipe are removed completely.
Nirbheek Chauhan
Rodrigo Lourenço
Jussi Pakkanen
Hemmo Nieminen
Fabio Porcedda
Thibault Saunier
Dima Krasner
Matthieu Gautier