Bruno Haible <br...@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
Description: PGP signature
