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.
Valgrind is a bit of a strange beast, in general use one isn't supposed
to link against valgrinds libs, they're non-PIC static libs, instead,
including the headers does magic to make valgrind work.
This patch implements a simple ValgrindDependency class subclassed from
PkgConfigDependency, that overwrites (effectively) only the
get_link_args method to always return an empty list. This solution may
seem strange, but I think that it follows the principle of least
surprise, and simplifies the most common use case for valgrind.
Essentially without this every valgrind consumer would be forced to
implement the following code to have a usable valgrind dependency
object:
_dep = dependency('valgrind', required : false)
if _dep.found()
valgrind_dep = declare_dependency(
compile_args : _dep.get_pkgconfig_variable('Cflags')
)
else
valgrind_dep = []
endif
While the above is workable, it's surprising behavior and the above code
snippet becomes boilerplate that everyone needs to copy into their meson
files.
Fixes#826
The MSVC static library tool, lib.exe, does not understand the same set
of arguments as the linker. Avoid a warning by not adding /DEBUG or /PDB
to the command line when invoking lib.exe
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).
Added and tested on MSYS2/MinGW which doesn't implement the required
semaphore locks in the multiprocessing module:
Traceback (most recent call last):
File "C:/msys64/mingw64/lib/python3.5\multiprocessing\synchronize.py", line 29, in <module>
from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'sem_unlink'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "run_project_tests.py", line 560, in <module>
(passing_tests, failing_tests, skipped_tests) = run_tests(all_tests, 'meson-test-run', options.extra_args)
File "run_project_tests.py", line 406, in run_tests
executor = conc.ProcessPoolExecutor(max_workers=num_workers)
File "F:/msys64/mingw64/lib/python3.5\concurrent\futures\process.py", line 390, in __init__
EXTRA_QUEUED_CALLS)
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\context.py", line 101, in Queue
return Queue(maxsize, ctx=self.get_context())
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\queues.py", line 42, in __init__
self._rlock = ctx.Lock()
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\context.py", line 65, in Lock
from .synchronize import Lock
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\synchronize.py", line 34, in <module>
" function, see issue 3770.")
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
See also:
https://bugs.python.org/issue3770https://github.com/mesonbuild/meson/issues/1323
According to 3770, the same problem also exists on OpenBSD, so this
will potentially also be useful there.
The actual fix is quite involved (#1526), so just disable this for now
since it's much worse to not be able to generate static libraries at
all vs a minor bug in static libraries getting stale objects (#1356)
Closes https://github.com/mesonbuild/meson/issues/1517