GNU bug report logs - #48113
Self-test timeout functionality

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Josefsson <simon <at> josefsson.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Marc Nieper-Wißkirchen <marc.nieper+gnu <at> gmail.com>,
 bug-automake <at> gnu.org, bug-gnulib <at> gnu.org
Subject: Re: Module suggestion: timeout
Date: Fri, 30 Apr 2021 11:24:04 +0200

[Message part 1 (text/plain, inline)]

Bruno Haible <bruno <at> clisp.org> writes:

> So, I don't think the "let's treat timeout like valgrind" approach is going
> to work. Instead, you need to design a way to deal with timeouts, independently.

Hi!  I think Marc's request for functionality to introduce timeouts for
self-tests is a good one.  However I reach the same conclusion as Bruno,
that having a module like valgrind-tests is probably not the best way to
solve it.  To me, having a timeout seems like an essential feature of a
self-test framework.  I know automake isn't primarily a self-test
framework, but it has concepts for it and the test framework has been
improved significantly over the years, so I think adding a timeout
functionality to automake makes sense.  What do bug-automake people
think?

The functionality could be conditioned on the coreutils 'timeout' tool,
and if that tool exists, and appears to work, running all self-tests
under that tool could be done automatically.  The default self-test
timeout be quite generous (say 17 hours?) but it should be easy to
modify both by end-user and project developer.  If we want to be
conservative, the functionality could be opt-in initially, and then
after a few years become the default behaviour.

Thoughts?

/Simon

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.