Re: AS_IF failure

[Eric Blake]

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