Re: use of make in AM_SANITY_CHECK

Karl Berry wrote:
>     make(1) in AM_SANITY_CHECK seems to be a logic error, since the user
>     may want to build with a different $MAKE,
>
> You're right. Crap. It never ends.
>
> In practice it probably doesn't matter, though.  Although in theory one
> can imagine that "make" succeeds while $MAKE fails, resulting in a false
> positive, in practice that seems next to zero probability to me. Much
> more likely is that "make" fails and $MAKE succeeds, and the only
> downside of that is an extra second of sleeping.
>   

The problem is that we still sleep unnecessarily in the sanity check.  
While there is no way to avoid sleeping if we need to /measure/ the 
filesystem timestamp resolution, few packages actually need that 
information (Automake itself is one of them, for its testsuite) and the 
sanity check can be (and previously was) done without actually measuring it.

>     have a way to revise AM_SANITY_CHECK that can avoid any sleep in the 
>     most common cases.
>
> Bruno's last patch already does that, doesn't it? I'll apply it shortly.
>   

No, that patch does not:  it promotes 
_AM_FILESYSTEM_TIMESTAMP_RESOLUTION to 
AM_FILESYSTEM_TIMESTAMP_RESOLUTION (removing the underscore), but still 
calls it as part of AM_SANITY_CHECK.

I propose first mostly reverting to the code in commit 
f6b3f7fb620580356865ebedfbaf76af3e534369:  revising AM_SANITY_CHECK to 
create a test file and immediately check if that file is newer than 
configure itself, then (if needed) sleep for one second, overwrite the 
test file and test again, then (if needed) sleep for one more second and 
repeat to allow FAT filesystems to be considered "sane". Then, replace 
the effect of commit 333c18a898e9042938be0e5709ec46ff0ead0797 and fix 
the problem with config.status not being newer than configure by adding 
an AC_CONFIG_COMMANDS_POST block that checks if config.status is newer 
than configure, and if not, sleeps one second and executes "touch 
config.status", then repeats that test once (again to accommodate FAT 
filesystem limitations) if needed.

In Mike Frysinger's situation of a Gentoo build with many small 
configure scripts, this /should/ result in at most one configure 
sleeping once, after which all of the other freshly regenerated 
configure scripts will already be old enough to avoid delays.


-- Jacob