[libvirt PATCH 0/2] meson: Add tests_timeout build option
See patch 2/2 for the rationale. Andrea Bolognani (2): meson: Rename tests-related build options meson: Add tests_timeout build option libvirt.spec.in | 2 +- meson.build | 8 +++++--- meson_options.txt | 5 +++-- tests/meson.build | 6 +++--- 4 files changed, 12 insertions(+), 9 deletions(-) -- 2.26.2
We already have two options that influence how 'ninja test' behaves and we're about to introduce a third one, so it makes sense to give them consistent names. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 2 +- meson.build | 6 +++--- meson_options.txt | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 379cf0d9be..90aeb6210c 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1185,7 +1185,7 @@ export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/%{name}.spec) -Dqemu_group=%{qemu_group} \ -Dtls_priority=%{tls_priority} \ %{?enable_werror} \ - -Dexpensive_tests=enabled \ + -Dtests_expensive=enabled \ -Dinit_script=systemd \ %{?arg_login_shell} diff --git a/meson.build b/meson.build index 33eaa9ff56..0820e4c895 100644 --- a/meson.build +++ b/meson.build @@ -127,14 +127,14 @@ endif # test options -if get_option('expensive_tests').auto() +if get_option('tests_expensive').auto() use_expensive_tests = not git else - use_expensive_tests = get_option('expensive_tests').enabled() + use_expensive_tests = get_option('tests_expensive').enabled() endif coverage_flags = [] -if get_option('test_coverage') +if get_option('tests_coverage') coverage_flags = [ '-fprofile-arcs', '-ftest-coverage', diff --git a/meson_options.txt b/meson_options.txt index 7838630c1e..43ce9b83de 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -3,8 +3,8 @@ option('packager', type: 'string', value: '', description: 'Extra packager name' option('packager_version', type: 'string', value: '', description: 'Extra packager version') option('system', type: 'boolean', value: false, description: 'Set install paths to system ones') option('runstatedir', type: 'string', value: '', description: 'State directory for temporary sockets, pid files, etc') -option('expensive_tests', type: 'feature', value: 'auto', description: 'set the default for enabling expensive tests (long timeouts), use VIR_TEST_EXPENSIVE to override') -option('test_coverage', type: 'boolean', value: false, description: 'turn on code coverage instrumentation') +option('tests_expensive', type: 'feature', value: 'auto', description: 'set the default for enabling expensive tests (long timeouts), use VIR_TEST_EXPENSIVE to override') +option('tests_coverage', type: 'boolean', value: false, description: 'turn on code coverage instrumentation') option('git_werror', type: 'feature', value: 'auto', description: 'use -Werror if building from GIT') option('rpath', type: 'feature', value: 'auto', description: 'whether to include rpath information in installed binaries and libraries') -- 2.26.2
- tl;dr: ((( (_)T(_) On a Wednesday in 2020, Andrea Bolognani wrote:
We already have two options that influence how 'ninja test'
ninja *test* [1]
behaves and we're about to introduce a third one, so it makes sense to give them consistent names.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 2 +- meson.build | 6 +++--- meson_options.txt | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in index 379cf0d9be..90aeb6210c 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1185,7 +1185,7 @@ export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/%{name}.spec) -Dqemu_group=%{qemu_group} \ -Dtls_priority=%{tls_priority} \ %{?enable_werror} \ - -Dexpensive_tests=enabled \ + -Dtests_expensive=enabled \ -Dinit_script=systemd \ %{?arg_login_shell}
diff --git a/meson.build b/meson.build index 33eaa9ff56..0820e4c895 100644 --- a/meson.build +++ b/meson.build @@ -127,14 +127,14 @@ endif
# test options
*test* options [2]
-if get_option('expensive_tests').auto() +if get_option('tests_expensive').auto() use_expensive_tests = not git else - use_expensive_tests = get_option('expensive_tests').enabled() + use_expensive_tests = get_option('tests_expensive').enabled() endif
coverage_flags = [] -if get_option('test_coverage') +if get_option('tests_coverage') coverage_flags = [ '-fprofile-arcs', '-ftest-coverage', diff --git a/meson_options.txt b/meson_options.txt index 7838630c1e..43ce9b83de 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -3,8 +3,8 @@ option('packager', type: 'string', value: '', description: 'Extra packager name' option('packager_version', type: 'string', value: '', description: 'Extra packager version') option('system', type: 'boolean', value: false, description: 'Set install paths to system ones') option('runstatedir', type: 'string', value: '', description: 'State directory for temporary sockets, pid files, etc') -option('expensive_tests', type: 'feature', value: 'auto', description: 'set the default for enabling expensive tests (long timeouts), use VIR_TEST_EXPENSIVE to override') -option('test_coverage', type: 'boolean', value: false, description: 'turn on code coverage instrumentation') +option('tests_expensive', type: 'feature', value: 'auto', description: 'set the default for enabling expensive tests (long timeouts), use VIR_TEST_EXPENSIVE to override')
VIR_*TEST*_EXPENSIVE [3] The singular spelling seems to be popular even within the context of this patch. And unlike its plural counterpart, it: 1) can actually be pronounced 2) involves less typing 3) 'test coverage' is actually a term https://en.wikipedia.org/wiki/Code_coverage 4) for 2/2, the timeout influences a single test, not all of them so it would make more sense. Jano
+option('tests_coverage', type: 'boolean', value: false, description: 'turn on code coverage instrumentation') option('git_werror', type: 'feature', value: 'auto', description: 'use -Werror if building from GIT') option('rpath', type: 'feature', value: 'auto', description: 'whether to include rpath information in installed binaries and libraries')
-- 2.26.2
On Wed, 2020-09-09 at 15:30 +0200, Ján Tomko wrote:
The singular spelling seems to be popular even within the context of this patch. And unlike its plural counterpart, it: 1) can actually be pronounced 2) involves less typing 3) 'test coverage' is actually a term https://en.wikipedia.org/wiki/Code_coverage 4) for 2/2, the timeout influences a single test, not all of them so it would make more sense.
I can do s/tests_/test_/g, no problem. I was actually wondering about that myself, and I figured I would just pick one of the two and then send it on the list to see whether anyone would push for the other one ;) -- Andrea Bolognani / Red Hat / Virtualization
The default timeout for tests is 30s, but that's not always enough time: the Valgrind test, for example, are currently special-cased because they take longer, and on certain architectures where powerful hardware is not (yet) available even the basic test programs might take more than 30s to complete. A concrete example of this happening and preventing a package build from finishing: https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=riscv64&ver=6.7.0-1&stamp=1599587548&raw=0 Make it possible to configure a different timeout for tests. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- meson.build | 2 ++ meson_options.txt | 1 + tests/meson.build | 6 +++--- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/meson.build b/meson.build index 0820e4c895..2d5b364979 100644 --- a/meson.build +++ b/meson.build @@ -141,6 +141,8 @@ if get_option('tests_coverage') ] endif +tests_timeout = get_option('tests_timeout') + # Detect when running under the clang static analyzer's scan-build driver # or Coverity-prevent's cov-build. Define STATIC_ANALYSIS accordingly. diff --git a/meson_options.txt b/meson_options.txt index 43ce9b83de..d048ed8dd6 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -5,6 +5,7 @@ option('system', type: 'boolean', value: false, description: 'Set install paths option('runstatedir', type: 'string', value: '', description: 'State directory for temporary sockets, pid files, etc') option('tests_expensive', type: 'feature', value: 'auto', description: 'set the default for enabling expensive tests (long timeouts), use VIR_TEST_EXPENSIVE to override') option('tests_coverage', type: 'boolean', value: false, description: 'turn on code coverage instrumentation') +option('tests_timeout', type: 'integer', value: 30, description: 'time (in seconds) after which a test case is considered failed') option('git_werror', type: 'feature', value: 'auto', description: 'use -Werror if building from GIT') option('rpath', type: 'feature', value: 'auto', description: 'whether to include rpath information in installed binaries and libraries') diff --git a/tests/meson.build b/tests/meson.build index 0a204c46e4..322904910e 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -582,7 +582,7 @@ foreach data : tests ], export_dynamic: true, ) - test(data['name'], test_bin, env: tests_env) + test(data['name'], test_bin, env: tests_env, timeout: tests_timeout) endforeach @@ -681,7 +681,7 @@ endif foreach name : test_scripts script = find_program(name) - test(name, script, env: tests_env) + test(name, script, env: tests_env, timeout: tests_timeout) endforeach add_test_setup( @@ -701,6 +701,6 @@ add_test_setup( '--suppressions=@0@'.format(meson.current_source_dir() / '.valgrind.supp'), '--error-exitcode=1', ], - # default timeout in meson is 30s + # Tests take a lot longer when run under Valgrind timeout_multiplier: 4, ) -- 2.26.2
On Wed, Sep 09, 2020 at 03:10:06PM +0200, Andrea Bolognani wrote:
The default timeout for tests is 30s, but that's not always enough time: the Valgrind test, for example, are currently special-cased because they take longer, and on certain architectures where powerful hardware is not (yet) available even the basic test programs might take more than 30s to complete.
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
A concrete example of this happening and preventing a package build from finishing:
Make it possible to configure a different timeout for tests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- meson.build | 2 ++ meson_options.txt | 1 + tests/meson.build | 6 +++--- 3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build index 0820e4c895..2d5b364979 100644 --- a/meson.build +++ b/meson.build @@ -141,6 +141,8 @@ if get_option('tests_coverage') ] endif
+tests_timeout = get_option('tests_timeout') +
# Detect when running under the clang static analyzer's scan-build driver # or Coverity-prevent's cov-build. Define STATIC_ANALYSIS accordingly. diff --git a/meson_options.txt b/meson_options.txt index 43ce9b83de..d048ed8dd6 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -5,6 +5,7 @@ option('system', type: 'boolean', value: false, description: 'Set install paths option('runstatedir', type: 'string', value: '', description: 'State directory for temporary sockets, pid files, etc') option('tests_expensive', type: 'feature', value: 'auto', description: 'set the default for enabling expensive tests (long timeouts), use VIR_TEST_EXPENSIVE to override') option('tests_coverage', type: 'boolean', value: false, description: 'turn on code coverage instrumentation') +option('tests_timeout', type: 'integer', value: 30, description: 'time (in seconds) after which a test case is considered failed') option('git_werror', type: 'feature', value: 'auto', description: 'use -Werror if building from GIT') option('rpath', type: 'feature', value: 'auto', description: 'whether to include rpath information in installed binaries and libraries')
diff --git a/tests/meson.build b/tests/meson.build index 0a204c46e4..322904910e 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -582,7 +582,7 @@ foreach data : tests ], export_dynamic: true, ) - test(data['name'], test_bin, env: tests_env) + test(data['name'], test_bin, env: tests_env, timeout: tests_timeout) endforeach
@@ -681,7 +681,7 @@ endif
foreach name : test_scripts script = find_program(name) - test(name, script, env: tests_env) + test(name, script, env: tests_env, timeout: tests_timeout) endforeach
add_test_setup( @@ -701,6 +701,6 @@ add_test_setup( '--suppressions=@0@'.format(meson.current_source_dir() / '.valgrind.supp'), '--error-exitcode=1', ], - # default timeout in meson is 30s + # Tests take a lot longer when run under Valgrind timeout_multiplier: 4, ) -- 2.26.2
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On a Wednesday in 2020, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:10:06PM +0200, Andrea Bolognani wrote:
The default timeout for tests is 30s, but that's not always enough time: the Valgrind test, for example, are currently special-cased because they take longer, and on certain architectures where powerful hardware is not (yet) available even the basic test programs might take more than 30s to complete.
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
There is --timeout-multiplier. Jano
A concrete example of this happening and preventing a package build from finishing:
Make it possible to configure a different timeout for tests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- meson.build | 2 ++ meson_options.txt | 1 + tests/meson.build | 6 +++--- 3 files changed, 6 insertions(+), 3 deletions(-)
On Wed, Sep 09, 2020 at 02:31:48PM +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:10:06PM +0200, Andrea Bolognani wrote:
The default timeout for tests is 30s, but that's not always enough time: the Valgrind test, for example, are currently special-cased because they take longer, and on certain architectures where powerful hardware is not (yet) available even the basic test programs might take more than 30s to complete.
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
It does but only if using meson command: meson test -t if the tests are started using ninja command: ninja test it is not possible to pass additional arguments to meson via ninja. Pavel
On Wed, Sep 09, 2020 at 03:38:21PM +0200, Pavel Hrdina wrote:
On Wed, Sep 09, 2020 at 02:31:48PM +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:10:06PM +0200, Andrea Bolognani wrote:
The default timeout for tests is 30s, but that's not always enough time: the Valgrind test, for example, are currently special-cased because they take longer, and on certain architectures where powerful hardware is not (yet) available even the basic test programs might take more than 30s to complete.
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
It does but only if using meson command:
meson test -t
if the tests are started using ninja command:
ninja test
it is not possible to pass additional arguments to meson via ninja.
So unless there's a blocker preventing use of "meson test -t" then it seems we don't need this patch. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, 2020-09-09 at 14:41 +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:38:21PM +0200, Pavel Hrdina wrote:
On Wed, Sep 09, 2020 at 02:31:48PM +0100, Daniel P. Berrangé wrote:
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
It does but only if using meson command:
meson test -t
if the tests are started using ninja command:
ninja test
it is not possible to pass additional arguments to meson via ninja.
So unless there's a blocker preventing use of "meson test -t" then it seems we don't need this patch.
Fedora seems to be using 'meson test' already; Debian uses 'ninja test' in debhelper compat level 12 but switched to 'meson test' with level 13, which doesn't look problematic otherwise and I should be able to adopt pretty quickly. I'm not sure about other distributions out there. Taking a step back, what are the reasons one might want to call either meson or ninja to run the test suite? -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Sep 09, 2020 at 03:56:08PM +0200, Andrea Bolognani wrote:
On Wed, 2020-09-09 at 14:41 +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:38:21PM +0200, Pavel Hrdina wrote:
On Wed, Sep 09, 2020 at 02:31:48PM +0100, Daniel P. Berrangé wrote:
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
It does but only if using meson command:
meson test -t
if the tests are started using ninja command:
ninja test
it is not possible to pass additional arguments to meson via ninja.
So unless there's a blocker preventing use of "meson test -t" then it seems we don't need this patch.
Fedora seems to be using 'meson test' already; Debian uses 'ninja test' in debhelper compat level 12 but switched to 'meson test' with level 13, which doesn't look problematic otherwise and I should be able to adopt pretty quickly.
I'm not sure about other distributions out there. Taking a step back, what are the reasons one might want to call either meson or ninja to run the test suite?
It appears that 'ninja test' is just a dumb shim to invoke 'meson test'. Given that using meson test directly looks much saner as you get the full range of functionality available. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, 2020-09-09 at 15:01 +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:56:08PM +0200, Andrea Bolognani wrote:
Taking a step back, what are the reasons one might want to call either meson or ninja to run the test suite?
It appears that 'ninja test' is just a dumb shim to invoke 'meson test'. Given that using meson test directly looks much saner as you get the full range of functionality available.
I think it's the other way around, isn't it? That is, 'meson test' is a wrapper for 'ninja test' which adds a bunch of functionality on top. Note that this doesn't necessarily contradict your conclusion above, I'm just trying to be sure I understand how things work :) -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Sep 09, 2020 at 04:17:21PM +0200, Andrea Bolognani wrote:
On Wed, 2020-09-09 at 15:01 +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:56:08PM +0200, Andrea Bolognani wrote:
Taking a step back, what are the reasons one might want to call either meson or ninja to run the test suite?
It appears that 'ninja test' is just a dumb shim to invoke 'meson test'. Given that using meson test directly looks much saner as you get the full range of functionality available.
I think it's the other way around, isn't it? That is, 'meson test' is a wrapper for 'ninja test' which adds a bunch of functionality on top.
That's not what the build.ninja says: build meson-test: CUSTOM_COMMAND all PHONY COMMAND = /usr/bin/meson test --no-rebuild --print-errorlogs DESC = Running$ all$ tests. pool = console build test: phony meson-test There's nothing else in the build.ninja that refers to execution of tests - it merely builds them. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, 2020-09-09 at 15:19 +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 04:17:21PM +0200, Andrea Bolognani wrote:
On Wed, 2020-09-09 at 15:01 +0100, Daniel P. Berrangé wrote:
It appears that 'ninja test' is just a dumb shim to invoke 'meson test'. Given that using meson test directly looks much saner as you get the full range of functionality available.
I think it's the other way around, isn't it? That is, 'meson test' is a wrapper for 'ninja test' which adds a bunch of functionality on top.
That's not what the build.ninja says:
build meson-test: CUSTOM_COMMAND all PHONY COMMAND = /usr/bin/meson test --no-rebuild --print-errorlogs DESC = Running$ all$ tests. pool = console
build test: phony meson-test
There's nothing else in the build.ninja that refers to execution of tests - it merely builds them.
So it is! And same for 'ninja install', as it turns out. Thanks for correcting my understanding :) -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Sep 09, 2020 at 03:56:08PM +0200, Andrea Bolognani wrote:
On Wed, 2020-09-09 at 14:41 +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:38:21PM +0200, Pavel Hrdina wrote:
On Wed, Sep 09, 2020 at 02:31:48PM +0100, Daniel P. Berrangé wrote:
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
It does but only if using meson command:
meson test -t
if the tests are started using ninja command:
ninja test
it is not possible to pass additional arguments to meson via ninja.
So unless there's a blocker preventing use of "meson test -t" then it seems we don't need this patch.
Fedora seems to be using 'meson test' already; Debian uses 'ninja test' in debhelper compat level 12 but switched to 'meson test' with level 13, which doesn't look problematic otherwise and I should be able to adopt pretty quickly.
I'm not sure about other distributions out there. Taking a step back, what are the reasons one might want to call either meson or ninja to run the test suite?
It might be more natural for users to run `ninja && ninja test` but since meson 0.54.0 it is possible to run `meson compile && meson test`. So the technically the only reason to use `meson test` instead of `ninja test` is to use all the options of meson test. Pavel
On Wed, 2020-09-09 at 16:09 +0200, Pavel Hrdina wrote:
On Wed, Sep 09, 2020 at 03:56:08PM +0200, Andrea Bolognani wrote:
Taking a step back, what are the reasons one might want to call either meson or ninja to run the test suite?
It might be more natural for users to run `ninja && ninja test` but since meson 0.54.0 it is possible to run `meson compile && meson test`.
So the technically the only reason to use `meson test` instead of `ninja test` is to use all the options of meson test.
It looks like you can even do 'meson install', so basically you can do everything without ever invoking ninja directly. Interestingly, the %meson RPMs macros, at least in the form they currently exist in Fedora, seem to only use meson instead of ninja for running tests in addition to the setup phase, where of course using ninja is not an option. I wonder if, over time, that will change... -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Sep 9, 2020 at 10:25 AM Andrea Bolognani <abologna@redhat.com> wrote:
On Wed, 2020-09-09 at 16:09 +0200, Pavel Hrdina wrote:
On Wed, Sep 09, 2020 at 03:56:08PM +0200, Andrea Bolognani wrote:
Taking a step back, what are the reasons one might want to call either meson or ninja to run the test suite?
It might be more natural for users to run `ninja && ninja test` but since meson 0.54.0 it is possible to run `meson compile && meson test`.
So the technically the only reason to use `meson test` instead of `ninja test` is to use all the options of meson test.
It looks like you can even do 'meson install', so basically you can do everything without ever invoking ninja directly.
Interestingly, the %meson RPMs macros, at least in the form they currently exist in Fedora, seem to only use meson instead of ninja for running tests in addition to the setup phase, where of course using ninja is not an option. I wonder if, over time, that will change...
The Meson macros are maintained as part of Meson itself upstream, and it was changed to use Meson directly with Meson 0.55.0: https://github.com/mesonbuild/meson/commit/0a61f511aa1960ac0d3f9b5e50e35f5f6... This change was inspired by the change done in Fedora for CMake: https://src.fedoraproject.org/rpms/cmake/c/4e79ea67732aecb6232c33dfff6ab0338... It is incredibly unlikely for Meson to switch back, because this abstraction makes it possible to trivially switch out backends without changing the interface. -- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, 2020-09-09 at 14:31 +0100, Daniel P. Berrangé wrote:
On Wed, Sep 09, 2020 at 03:10:06PM +0200, Andrea Bolognani wrote:
The default timeout for tests is 30s, but that's not always enough time: the Valgrind test, for example, are currently special-cased because they take longer, and on certain architectures where powerful hardware is not (yet) available even the basic test programs might take more than 30s to complete.
Does Meson not have a standard way to increase the default timeout globally ? It feels like this scenario of building on slow hardware could hit any application, so surprised we need to add our own args for this
Not that I could find... To be honest, some parts of Meson and Ninja are documented in a way that is not immediately obvious to me, so I might very well have missed it. Note that 'meson test' supports -t TIMEOUT_MULTIPLIER --timeout-multiplier TIMEOUT_MULTIPLIER Define a multiplier for test timeout, for example when running tests in particular conditions they might take more time to execute. but there doesn't seem to be a 'ninja test' equivalent; I'm also unclear on how a multiplier passed this way would interact with timeout_multiplier as provided to add_test_setup() calls, which is something that we use for Valgrind. -- Andrea Bolognani / Red Hat / Virtualization
participants (5)
-
Andrea Bolognani -
Daniel P. Berrangé -
Ján Tomko -
Neal Gompa -
Pavel Hrdina