pre_flush_set and post_flush_set are almost always empty, so we can use
extend() instead of a for...in loop to add the previous elements of
self._container.
We can also skip the conversion from deque to list since pre_flush is
always appended on the right side.
On a QEMU build the time spent in flush_pre_post goes from 1.4 to 0.5
seconds.
The linker always args, as the name implies, should always be included. For
example, the AIX get_allow_undefined_link_args are a syntax error unless
the AIX get_linker_always_args are also used.
Without the parenthesis, the command evaluates to `[]` if
`use_llvm_cov` is `False`.
Also fix tests to actually check whether or not coverage reports are
generated.
Fixes https://github.com/mesonbuild/meson/issues/7553
Without the -Xany flag, the ar command will complain when an .o file is
compiled for the non-default bit width. This change is necessary to allow
64-bit builds via a native (or cross) file.
Without this, MSVC and MSVC_VERSION won't be set by CMake during
platform detection, and the compiler will be an undefined mixture of
GNU and MSVC. In particular, find_package(opencv) will fail on Windows
when building with MSVC.
This is required to make `-include /path/to/custom/target.hpp`
work. This setup is used by wxWidgets and this PR is
required to use wxWidgets as a CMake subproject.
According to the specification:
https://testanything.org/tap-specification.html#skipping-tests
The harness should report the text after # SKIP\S*\s+ as a reason for
skipping.
(it's not exactly like the TODO directive, the phrasing/presentation of
the spec could be improved).
The compilers_detect function is only used in the qt module, which
checks every time before using a specific compiler, if it is found.
e.g.
meson.build:10:6: ERROR: MOC sources specified and couldn't find moc-qt5, please check your qt5 installation
In fact, the current check means we never even hit this error to begin
with, because we previously died on the uninformative error:
meson.build:10:6: ERROR: Program(s) ['moc'] not found or not executable
which doesn't actually tell the user why this matters, and is all around
a waste of time.
Fixes#5582
* mtest: TestResult.SKIP is not a failure
If some but not all tests in a run were skipped, then the overall result
is given by whether there were any failures among the non-skipped tests.
Resolves: https://github.com/mesonbuild/meson/issues/7515
Signed-off-by: Simon McVittie <smcv@debian.org>
* Add test-cases for partially skipped TAP tests
issue7515.txt is the output of one of the real TAP tests in gjs, which
failed as a result of #7515. The version inline in meson.build is
a minimal reproducer.
Signed-off-by: Simon McVittie <smcv@debian.org>
The `debug` builtin option does not control whether or not the debug
CRT is used. Without this fix, when buildtype=debugoptimized or when
debug=true + b_vscrt=md, we will try to link to the debug libraries
found via cmake while linking with `/release`, which will cause a link
failure.
Windows Git users with symlinks have a constantly dirty repo from
this "a_symlink". This change generates a symlink in the build directory
when the test is run.
There is nothing to "warn" about, this is a completely routine
occurence. OTOH, when something is corrupted, we should warn. Keep
the red color and "WARNING:" prefix in that case.
Example output:
$ ninja -C build
Regenerating configuration from scratch: Build directory has been generated with Meson version 0.55.999, which is incompatible with current version 0.56.0.
The Meson build system
Version: 0.56.0
...
Since upgrading Boost to version 1.73, this test segfaults on macOS
when dynamically linked. Disable it to keep the rest of the CI
reliable.
Mitigates: #7535
Signed-off-by: Simon McVittie <smcv@debian.org>
Meson calls `path/to/clang++ --version` to guess which build toolchain the
user has picked to build the source code. For the Qualcomm LLVM toolchain,
the output have an unusual output as shown below:
```
clang version 8.0.12
Snapdragon LLVM ARM Compiler 8.0.12 (based on llvm.org 7.0+)
Target: arm-unknown-linux-gnueabi
Thread model: posix
Repository: (ssh://git-hexagon-aus.qualcomm.com:...)
InstalledDir: /pkg/qct/software/llvm/release/arm/8.0.12/bin
```
Another unusual pattern is the output of `path/to/ld.qcld --version`:
```
ARM Linker from Snapdragon LLVM ARM Compiler Version 8.0.12
ARM Linker based on LLVM version: 8.0
```
The Meson logic is modified accordingly so that Meson can correctly
determine toolchain as "LLVM aarch64 cross-compiler on GNU/Linux64 OS".
This is the expected output of
`meson --native-file native_file.ini --cross-file cross_file.ini build/aarch64-debug/`:
```
...
C++ compiler for the host machine: ... (clang 8.0.12 "clang version 8.0.12")
C++ linker for the host machine: ... ld.lld 8.0.12
...
```