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

Reply via email to