[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AS_IF failure

From: Eric Blake
Subject: Re: AS_IF failure
Date: Wed, 20 Aug 2008 19:46:15 +0000 (UTC)
User-agent: Loom/3.14 (

Ralf Wildenhues <Ralf.Wildenhues <at>> writes:

> Yep.  It's a timing problem: the `script' from the first test has the
> same time stamp as the `' 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 

> 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/ (AS_IF and AS_CASE): Use `autom4te --force' for
>     second script.
>     * tests/ (autotools and whitespace in file names): Add
>     --force for repeated invocations.

Go ahead and commit.

Eric Blake

reply via email to

[Prev in Thread] Current Thread [Next in Thread]