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
