Bruno Haible wrote:
[I'm writing to automake@gnu.org because bug-autom...@gnu.org appears to be equivalent to /dev/null: no echo in https://lists.gnu.org/archive/html/bug-automake/2024-06/threads.html nor in https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake, even after several hours.]In configure scripts generated by Autoconf 2.72 and Automake 1.16.90, one of the early tests checking filesystem timestamp resolution... takes 7 seconds! Seen e.g. on NetBSD 10.0. Logging the execution time, via sh -x ./configure 2>&1 | gawk '{ print strftime("%H:%M:%S"), $0; fflush(); }' > log1 I get the attached output. There are 6x sleep 1 4x sleep 0.1 That is, 6.4 seconds are wasted in sleeps. IBM software may do this; but GNU software shouldn't. AFAIU, the 4x sleep 0.1 are to determine whether am_cv_filesystem_timestamp_resolution should be set to 0.1 or to 1. OK, so be it. But the 6x sleep 1 are to determine whether am_cv_filesystem_timestamp_resolution should be set to 1 or 2. 2 is known to be the case only for FAT/VFAT file systems. Therefore here is a proposed patch to speed this up. On NetBSD, it reduces the execution time of the test from ca. 7 seconds to ca. 0.5 seconds.
The problem with the proposed patch is that it tries to read a filesystem name instead of testing for the feature. This would not be portable to new systems that use a different name for their FAT filesystem driver.
I think the test can be better optimized for the common case by first checking if stat(1) from GNU coreutils is available ([[case `stat --version` in *coreutils*) YES;; *) NO;; esac]]) and, if it is (common case and definitely so on the GNU system), checking [[case `stat --format=%y .` in *:??.000000000) SUBSEC_RESOLUTION=no;; *) SUBSEC_RESOLUTION=yes;; esac]] to determine if sub-second timestamps are likely to be available; this has a 1-in-actual-ticks-per-second of giving a false negative. These checks would be very fast, so could also be repeated with the access and inode change timestamps and/or extended to other files (`stat *`) for better certainty. The basic concept should be sound, although the pattern matching used in the examples is a first cut.
The essential idea is that the fractional part beyond what the filesystem actually records will always read as zero, and unpacking an archive is not instant, so we should see every implemented fractional bit set at least once across files in the tree containing configure.
To handle filesystems with 2-second timestamp resolution, check the timestamp on configure, and arrange for autoconf to ensure that the timestamp of a generated configure script is always odd---that least-significant bit will be dropped when the script is unpacked on a filesystem with 2-second timestamp resolution.
If stat from GNU coreutils is not available, fall back to the current sleep(1)-based test and just eat the delay in the name of portability. The test checks only for "coreutils" because very old versions did not say GNU. A better, functional test for stat(1) is probably also possible.
-- Jacob
