On Fri, Oct 23, 2026 at 01:51:04PM -0600, Karl Berry wrote: > Hi Kamila, > > I find myself copy-pasting this feature over and over > in my Automake scripts, as seen in e.g. > https://github.com/iczelia/balrogg/blob/trunk/Makefile.am > > Since it's useful for you, I have no objection, but I agree with John > that such a thing looks challenging to implement portably.
We have test timeouts in the Texinfo package, in the tests of the 'info' program. I think it could be okay for tests to have their own timeout, in addition to a timeout from Automake. It could be useful where people build lots of packages and test them automatically, so that builds don't hang on their system, possibly consuming system resources. Timeouts in the tests themselves are able to do more cleaning up (e.g. of temporary files, or spawned processes), so it is better if tests do their own cleaning up. An Automake timeout would be useful in case in-test timeouts failed for some reason. You can see the code in the info/t/Init-test.inc code in the Texinfo sources, in case this is useful. (As I remember, it took a few attempts to get this to work reliably(*), although we have not touched the code for many years now.) (*) You can see I made several responses at https://stackoverflow.com/questions/5161193/how-to-kill-a-child-process-after-a-given-timeout-in-bash with different ideas how to do this. The problem is complicated because our tests spawn a background process, which we want to be able to kill. We do this with a command like (sleep $TEXINFO_INFO_TESTS_TIMEOUT ; kill $ginfo_pid) & This kills the process after the specified delay. We also keep the PID of the killer subshell and kill the subshell that is waiting to kill the process if the process exits first. This probably has a race condition but as I remember, the timeout rarely runs (it happened when running a slow test on a slow test machine, hence the need for the length of the timeout to be configurable). (The problem could be something like, the program exits naturally, but before we can kill the killer subshell, the timeout period is reached, and another process gets the same PID, and the killer subshell kills the wrong process.) This is probably extremely unlikely to happen, yet a simpler and more reliable method of timing out the sub-process would be appreciated. So as you can see, the method we use is somewhat convoluted. I wonder if it would be as simply as just using the "timeout" command from coreutils if it is available, along with the shell "wait" builtin. > OTOH, if it doesn't work reliably on Windows, it could just become a > no-op with a warning. We aren't obliged to implement every feature > equally on nonfree systems. Pretty much anything else would be a better > way to spend precious development time. > > Unfortunately, zsh can't do it > > Where does zsh come into it? If the test is written specifically in zsh? > > interactive programs + AM_TEST_TIMEOUT > > Yeah, I wouldn't worry about that. I doubt anyone using automake runs > truly interactive tests requiring input from the user in real time. More > or less the whole point is to avoid such things :). --thanks, karl. >
