Hi Jacob, > > 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 can amend the patch so that it uses `uname -s` first, and does the optimization only for the known systems (Linux, macOS, FreeBSD, NetBSD, OpenBSD, Solaris). > 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]]) Sure, if GNU coreutils 'stat -f' is available, things would be easy. But typically, from macOS to Solaris, it isn't. You can't achieve portability by using a highly unportable program like 'stat'. That's why my patch only uses 'df' and 'mount'. > 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 I don't care much about the 0.4 seconds spent on determining sub-second resolution. It's the 6 seconds that bug me. > 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 Since a tarball can be created on ext4 and unpacked on vfat FS, this would mean that autoconf needs to introduce a sleep() of up to 1 second, _regardless_ on which FS it is running. No, thank you, that is not a good cure to the problem. Bruno
