On 13/04/2020 23:58, Karl Berry wrote:
Hi Harald and all - well, Paul or Jim or any other automake worker will
know better than me, but my reactions, FWIW:
This caused intermittent failures in automake's t/subobj.sh test, which
This problem seems like the tip of the iceberg to me. With this change,
any dependency which gets updated in the same second as the target will
now have to get remade. Possibly looping forever, it seems to me?
Hi Karl,
A dependency is a file that needs to already exist beforehand. It is not
going to get updated by the command that creates the target. For
instance, for the dep configure.ac, one of the output files is
autom4te.cache/traces.0. If configure.ac is modified,
autom4te.cache/traces.0 needs to be updated, but the command that
updates autom4te.cache/traces.0 does not modify configure.ac at the same
time. My patch may cause autom4te.cache/traces.0 to be updated multiple
times in the worst case, but that's harmless and only lasts a second at
most.
I have not seen a deluge of (or any) reports about timestamp precision
being a problem before this.
It's probably pretty rare. I only saw it when running the automake
testsuite on an otherwise idle system, and even then not reliably. I
cannot speak for others, but that's not how I usually run the testsuite:
normally the system is busy with other stuff as well, slowing it down
enough for the automake test to pass.
runs aclocal+automake, modifies configure.ac, and immediately re-runs
aclocal+automake. On sufficiently fast computers, this would not update
the cache files.
Maybe aclocal and/or automake and/or other autoprograms should just
sleep 1 before exiting (or at whatever crucial junctures) if this
problem must be avoided at all costs.
But better -- as Paul, I guess, said, how about if up_to_date_p uses
subsecond timestamps if available, so the < test remains unchanged?
After all, if subsecond timestamps are not available, it's highly
probable that it's an old machine and it's all a non-issue. --best, karl.
Leaving the check as < is wrong, but it is also inconsistent with what
autom4te does outside of this module. From bin/autom4te.in:
995 # Read the cache index if available and older than autom4te itself.
996 # If autom4te is younger, then some structures such as C4che might
997 # have changed, which would corrupt its processing.
998 Autom4te::C4che->load ($icache_file)
999 if -f $icache && mtime ($icache) > mtime ($0);
Note how this only reads the cache file if it's newer, not if it has the
same mtime.
And I would not be too confident that nobody is still using file systems
without sub-second precision on modern machines. For better or worse,
FAT is the most universally accepted file system, and for that reason it
is widely used. It does not even support second precision timestamps.
Cheers,
Harald van Dijk
