Also don't resolve -lfoo args only when libpaths are defined.
cc.find_library() also searches in the toolchain directories, and the
static library might be there.
Older versions of GDC had broken support for the -MQ flag (resulting in
a compiler error). New versions of GDC have this issue fixed (some older
versions received a backport). Starting with GCC 7.1 we can assume
dependency generation to always work reliably.
A hard error makes this feature useless in most cases since a static
library usually won't be found for every library, particularly system
libraries like -lm. Instead, warn so the user can provide the static
library if they wish.
This feature will be expanded and made more extensible and more usable
in the future.
Closes https://github.com/mesonbuild/meson/issues/2785
We missed one particular edge-case in #2413: when the generated vala
file is inside --basedir, the path is not just the basename.c
Since this case can never happen in a project test, this includes a unit
test for the same.
Closes https://github.com/mesonbuild/meson/issues/815
Starting with VS 2017 if the output of any command run by VS contains
the word Error it will interpret that as a fatal error, even if the exit
error code is zero.
This messes up the unit tests on VS 2017, because we sometimes want to
deliberately ignore error messages.
Change "Error" to "Problem" to mitigate this issue until a more
permanent solution is found.
Fix exception handling of missing rustc, by making it look like the other
compiler detectors
Traceback (most recent call last):
File "/wip/meson/mesonbuild/environment.py", line 699, in detect_rust_compiler
p, out = Popen_safe(compiler + ['--version'])[0:2]
[...]
FileNotFoundError: [Errno 2] No such file or directory: 'rustc': 'rustc'
During handling of the above exception, another exception occurred:
[...]
File "/wip/meson/mesonbuild/environment.py", line 701, in detect_rust_compiler
popen_exceptions[compiler] = e
TypeError: unhashable type: 'list'
Since PR #2884, this is failing with an exception
Keep the behaviour we have had since PR #1810 (0.41.0), that ordering
comparisons of different types fail with an InterpreterException.
Also warn about equality comparisons of different types, which will one day
become an error, as per PR #2884.