On 26/5/26 22:14, Daniel Henrique Barboza wrote:
Hi,
I happen to use 'ninja -C build test to do a (usually) quick sanity test
on patches and changes and whatnot. An usual run of this target tests
around 327 individual tests with the RISC-V stuff I usually build.
After pulling today's master 'ninja -C build test' is now running a
whooping
1366 tests. Here's an example:
$ ninja -C build -j 9 test
ninja: Entering directory `build'
mkvenv: checking for pygdbmi>=0.11.0.0
mkvenv: installing pygdbmi==0.11.0.0
[2/3] Running all tests
[1-12/1366] (....)
(....)
[250-260/1366] 🌕 block-qcow2-optional+block-slow - qemu:io-qcow2-014
[250-261/1366] 🌖 block-qcow2-optional+block-slow - qemu:io-qcow2-014
[252-262/1366] 🌒 block-qcow2-optional+block-slow - qemu:io-qcow2-026
(...)
I noticed a lot of these "optional+block-slow" tests being ran now,
something that
wasn't happening before.
If I use 'make check' I have the results I was having with 'ninja -C
build test'
before the recent changes.
I tried to bisect and got to this commit:
commit daf0d008822be3cb14cdb533f7237c3c789bc373 (HEAD)
Author: Daniel P. Berrangé <[email protected]>
Date: Mon Jan 12 13:01:49 2026 +0000
iotests: remove redundant meson suite for iotests
Cc'ing developers involved in this commit and Alex.
From what I can tell this commit triggered (unintended?) stuff that was
already in the
code. In other words I am not sure if this commit is actually the
culprit, so I am
reluctant to even call this a bug.
My question is: should I be using 'ninja test'? It seems to me that the
common practice
is to use 'make check' and maybe I've been using an "unsupported"
testing scheme.
This is what was explained to me on #irc when I complained about a
similar issue, however I still use ninja first because it is much faster
than having make parsing Makefiles not triggering any rule before
calling ninja. When this (rarely) fails I go back to 'make'.
Some developers like Pierrick better understand ninja and use it
directly.
Cheers,
Daniel
