Print the (shortened) output of the failed tests as they happen.
If neither --verbose nor --print-errorlogs was specified, omit the
summary of failures, because it is pretty much the same as the earlier
output of "meson test".
In non-parallel verbose mode the output of the test/benchmark
is not buffered, therefore the command line is only printed by
ConsoleLogger for failing tests and only after the test has run.
Verbose mode is designed mostly for CI systems, where output must
be human readable but is generally consumed from a browser with "Find"
commands rather than from a terminal. With this usecase in mind, it
is better to provide as much detail as possible, so add more output
and just tell the user which tests have started. Do so, using the
recently introduced TestResult.RUNNING state.
Ensure that all the required modifications are included in the logs.
This makes it possible for users to cut-and-paste from the logs when
trying to reproduce failures outside Meson.
Right now the same code is used to print the logs for both the console
and the text log. Differentiating them lets the important bits of
the console output stand out, and makes the console output a bit more
readable.
Automatically colorize the text when printing the AnsiDecorator, based
on the result of mlog.colorize_console(). This is how AnsiDecorator
is used most of the time anyway.
This adds a test which makes use of an install:yes static library that
depends on another static library. This triggers a promotion to
link_whole_target inside meson which takes different code paths in
certain places.
Also makes use of .F90 source (capital F) to test for case
(in)sensitivity.
This commit performs some cleanup for the msvc and clang-cl arguments.
* "Disable Debug" (`/Od`) is no longer manually specified for optimization levels {`0`,`g`} (it is already the default for MSVC).
* "Run Time Checking" (`/RTC1`) removed from `debug` buildtype by default
* Clang-CL `debug` buildtype arguments now match MSVC arguments
* There is now no difference between `buildtype` flags and `debug` + `optimization` flags
Compiler tests, such as checking for atomics support, could fail
when compiling to WebAssembly multithreaded targets because the
compiler tests got compiled to 'output.wasm'.
Using the '.wasm' suffix in recent versions of emscripten engages
STANDALONE_WASM mode, which disables features that require a JS
runtime like shared memory.
This created false negatives on support of those features when
building a library to be linked into an executable that is not
in STANDALONE_WASM mode.
Changing these to 'output.o' will continue to produce WebAssembly
object files, but they will no longer be configured for standalone
runtime mode.
[why]
In test case 10 the project is installed twice. This has been introduced
with commit
55abe16 unit tests: Test that relative install_rpath works correctly
where the cxx tests where added by copy and paste.
[how]
First test all build rpaths, then after install all install rpaths.
[note]
The aforementioned commit is a bit strange in that it adds a tests with
a relative rpath with cxx files but not with c files.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If we build and test a library we need to make sure that we find the
currently build library object first, before an older system installed
one.
This can be broken if the library in question is installed in a custom
path, and another library we depend on also is installed there.
[how]
Just move the rpath to the current build artifacts to the front.
Solves #8030.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
In Fortran it is common to use capital F in the suffix (eg. '.F90') if
the source file makes use of preprocessor statements. Such files should
probably be treated like all other fortran files by meson.
Case insensitivity for suffixes was already implemented several places
in meson before this. So most likely, the few places changed here were
oversights anyway.
Using verbose mode dropped stdout/stderr from the logs, because
it was not captured.
Now that we can easily stick code in the middle of the reading of
stdout/stderr, use that to print stdout and stderr on the fly
while also capturing them for the logs. The output is line-buffered.
As a side effect, this also fixes a possible deadlock due to
not using ensure_future around stdo_task and stde_task. In
particular:
- the stdo_task coroutine would not terminate until the test closed
stdo_task
- the stde_task coroutine would not start until the stdo_task
coroutine finished
Therefore, the test could get stuck waiting for its parent to
read the contents of stderr, but that would not happen because
Meson was still in the stdo_task coroutine.
There are still caveats here. Rust/cargo handles generated sources by
writing out all targets of a single repo into a single output directory,
setting a path to that via a build-time environment variable, and then
include those files via a set of functions and macros. Meson's build
layout is naturally different, and ninja makes working with environment
variables at compile time difficult.
Fixes#8157
we have two functions to do the exact same thing, and they're basically
implemented the same way. Instead, let's just use the BuildTarget one,
as it's more generally available.
The /ZI flag adds in "Edit and Continue" debug information, which will
cause massive slowdown. It is not a flag that we should be adding by
default to debug builds.
/Zi will still be added.
Move the logic to start the read/decode
tasks to TestSubprocess and keep SingleTestRunner simple.
The lines() inner function is tweaked to produce stdout as a future.
This removes the nonlocal access (which is not possible anymore
when the code is moved out of _run_cmd), and also lets _run_cmd
use "await stdo_task" for both parsed and unparsed output.
After the next patch, we will need to complete parse_task before
stdo_task (because parse_task will not set the "stdo" variable
anymore but it will still collect stdout just like now). Do
the change now to isolate the more complicated changes.
The new behavior of interrupting the longest running test with Ctrl-C is useful
when tests hang, but not when the run is completely broken for some reason.
Psychology tells us that the user will compulsively spam Ctrl-C in this case,
so exit if three Ctrl-C's are detected within a second.
Paolo Bonzini
Dylan Baker
Jonas Lundholm Bertelsen
Xavier Claessens
Marios Staikopoulos
Brion Vibber
Volker Weißmann
Jussi Pakkanen
Fini Jastrow