This will make future patches nicer.
Note that we need to handle these somewhat late because of the
dependency on information about the compiler and the flags it
supports.
Signed-off-by: Andrea Bolognani
---
meson.build | 57 +++--
1 file
It only makes sense to enable expensive tests when tests are
enabled. Disallow invalid configurations.
Signed-off-by: Andrea Bolognani
---
meson.build | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index ed9a07942d..7ec2a6fd1e 100644
---
There are some cases in which we automatically disable tests when
using Clang as the compiler. If the user has explicitly asked for
tests to be enabled, however, we should error out instead of
silently disabling things.
Signed-off-by: Andrea Bolognani
---
meson.build | 6 +-
1 file changed,
Andrea Bolognani (6):
meson: Do less when not building from git
meson: Move all handling of test options together
meson: Handle -Dtests=enabled with Clang
meson: Make -Dexpensive_tests depend on -Dtests
meson: Disable all tests when tests are disabled
meson: Rename build_tests ->
Currently, passing -Dtests=disabled only disables a subset of
tests: those that are written in C and thus require compilation.
Other tests, such as the syntax-check ones and those that are
implemented as scripts, are always enabled.
There's a potentially dangerous consequence of this behavior:
As explained in the comment, the syntax-check machinery uses git
to figure out the list of files it should operate on, so we can
only enable it when building from git.
Despite only registering the various tests with meson in that
case, however, we unconditionally perform a bunch of preparation
Given that this variable now controls not just whether C tests
are built, but also whether any test at all is executed, the new
name is more appropriate.
Update the description for the corresponding meson option
accordingly.
Signed-off-by: Andrea Bolognani
---
build-aux/meson.build | 2 +-
On Wed, Sep 27, 2023 at 08:53:41PM +0200, Erik Skultety wrote:
> While we have already descriptive articles on our GitLab CI, there's recently
> been some work on the CI front where a few sections deserve some updates.
>
> Erik Skultety (7):
> docs: ci-runners: Add a note on a new runner