On 5/7/25 12:39 AM, Thomas Huth wrote:
Then I don't understand the previous argument from Thomas to not make
thorough the default: "The thorough functional tests download a
lot of assets from the internet, so if someone just runs "meson test"
without further parameters, I think we should not trigger these
downloads in that case". It's what precache-functional is doing.

precache-functional is *only* called when you run "make check-functional",
i.e. when you know that you want to run the functional tests that might
download assets from the internet. It's not called when you run the normal
"make check".

Are you sure ?  If that's the case it was *not* my intention when i
added precaching - I thought that "make check"  would call
"make check-functional" and thus trigger precaching ?

"check-functional" is not part of the normal "check" target - on purpose
since we don't want to trigger downloads by surprise when people just run
"make check". That's also why we have separate "functional" CI jobs in the
gitlab CI, since otherwise this would be handled by the normal "check" jobs
already.


`make check` calls build/pyvenv/bin/meson test --no-rebuild -t 1, which triggers func-quick by default, triggering associated downloads, since QEMU_TEST_NO_DOWNLOAD=1 is not set for this target, except if I missed another hidden hack somewhere. `meson test --no-suite func-quick --no-suite func-thorough` should be what make check should do instead, or we need another "setup", to exclude functional-quick from quick default.

It seems that we just have some confusion steaming from our own "makefile abstraction layer", when we could simply use builtin meson test command for that, which works for all workflows (single vs multiple tests). It reinforces my opinion that setups are awkward and that's better to use meson test directly with --setup thorough being the default, for better or worse. In case a developer wants a specific suite, it's also easy to select it with '--suite', and list them with '--list'.

That said, I'm dropping this series, and won't pursue asking to change the default, since this opinion is not the established consensus.

   Thomas


Regards,
Pierrick

Reply via email to