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.
Setting MALLOC_PERTURB_ to a non-zero value is fine for regular test
cases. It helps catching bugs, but also comes with some runtime
overhead.
This overhead is noticeable for benchmarks when compared to running them
directly instead of through Meason.
Therefore, MALLOC_PERTURB_ is not touched for benchmarks.
closes#3034
Previously, Meson was showing a subproject being downloaded after later
claiming it doesn't exist.
This patch shows the actual error to clarify why the given subproject
can not be used.
The '+' and 'U' cases should not happen normally because we don't run
any git commands if the subproject directory exists and contains
a meson build file. However, if the user accidentally messed up the
subproject checkout to a version that had no build files, we would
error out with an assertion.
After PR #2662, running test case common/125 shared module/ on Cygwin gets
me:
$ ninja -C _build
ninja: Entering directory `_build'
[7/7] Linking target prog.exe.
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: warning: --export-dynamic is not supported for PE+ targets, did you mean --export-all-symbols?
Also, fix doc for correct version of first apperance.
Future work: Notwithstanding the hint that ld gives, these options are not
equivalent, and it's not clear we should be using it here:
--export-all-symbols is the default behaviour, and if the exports are
restricted by explicit annotations or a .def file, this option might be
overriding that...
makise-homura
Nirbheek Chauhan
Matthias Klumpp
Caio Marcelo de Oliveira Filho
Hemmo Nieminen
Niklas Claesson
Jon Turney
Jussi Pakkanen
Dylan Baker
Alex Hirsch
Leon Krause
Benjamin Redelings