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.
PR #2527 suggests "making failing tests more strict about failing
gracefully".
To achive this, make meson exit with distinct exit statuses for meson errors
and python exceptions, and check the exit status is as expected for failing
tests.
I can't see how to write a test for this, within the current framework.
You can test this change by reverting the fix (but not the test) from commit
1a159db8 and verifying that 'test cases/failing/66 string as link target'
fails.
Currently we try both C and C++ when determining which PCH files to
include. The problem with this approach is that if there are no C or C++
files (only headers) and the target has both C and C++ sources then the
PCHs will be passed to the wrong compiler.
The solution is less code, we already have the compiler, the compiler
knows what language it is, so we don't need to walk both C and C++.
Fixes#3068
Since c2a5ac39, MesonApp.generate() closes the logfile before returning,
which means that when invoked by mesonmain.run(), any MesonException is not
logged there.
MesonApp.generate() does not appear to have any other users I can find.
This somewhat reduces the diagnostic value of the logfile.
This also interacts badly with running project tests in CI, as _run_tests
chooses to report the logfile contents, rather than stdout, for the
configure step, and it thus doesn't report any configure error which caused
a test failure.
makise-homura
Nirbheek Chauhan
Matthias Klumpp
Aleksey Filippov
Nirbheek Chauhan
Caio Marcelo de Oliveira Filho
Jussi Pakkanen
Eric Engestrom
David Fort
Hemmo Nieminen
Martin Ejdestig
Niklas Claesson
Jon Turney
Dylan Baker
Amit D