Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes: > > Yep. It's a timing problem: the `script' from the first test has the > same time stamp as the `script.as' from the second test, tricking > autom4te to think that its output is already up to date.
This begs the question - should we teach autom4te to automatically enable --force if the output file exists but has a timestamp of now, within the resolution detected for the filesystem? But until such a fix is evaluated (which I don't mind doing post-2.63, if necessary), using --force is the right approach. > > I got this to trigger on my x86 system in about one third of the cases. > The local file system has one-second resolution. I'm kind of guessing > that m4 speed improvements helped to make this race more likely. And explains why I was failing to reproduce on cygwin - NTFS has a better granularity and a worse fork time (the likelihood of completing autom4te in under a second is pretty slim when you've burned most of that second just starting perl). > OK? Should I also reset the limit to 1000 in the AS_IF test, Eric? I don't know if that will cause any shells to fall over (remember, bash fell over at 2500), but I also don't mind if you turn it back up, seeing as how we haven't yet identified any shell that fails at 1000. Fortunately, my factorization into [limit] makes tweaking the limit easier than when I first wrote the test. > Avoid timestamp races for updated input. > > * tests/m4sh.at (AS_IF and AS_CASE): Use `autom4te --force' for > second script. > * tests/tools.at (autotools and whitespace in file names): Add > --force for repeated invocations. Go ahead and commit. -- Eric Blake
