1.16.90 regression: configure now takes 7 seconds to start

Bruno Haible <[email protected]> Sat, 08 Jun 2024 00:27:39 +0200
Newsgroups gmane.comp.sysutils.automake.general
Message-ID <4122580.anssfa2V6d@nimes>
[I'm writing to [email protected] because [email protected]
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.
log1.xz (application/x-xz, 115.5 KB) - not displayed
0001-automake-Save-up-to-6-seconds-of-configure-time.patch (text/x-patch, 2.1 KB)
From 6a2f73a326b332a2692c8c46e8403d8d658a3d45 Mon Sep 17 00:00:00 2001
From: Bruno Haible <[email protected]>
Date: Sat, 8 Jun 2024 00:23:30 +0200
Subject: [PATCH] automake: Save up to 6 seconds of configure time.

* m4/sanity.m4 (_AM_FILESYSTEM_TIMESTAMP_RESOLUTION): Use 'df' and
'mount' to quickly exclude the case of a VFAT file system.
---
 m4/sanity.m4 | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/m4/sanity.m4 b/m4/sanity.m4
index 4504ef878..b6bf160c9 100644
--- a/m4/sanity.m4
+++ b/m4/sanity.m4
@@ -32,8 +32,38 @@ AC_CACHE_CHECK([filesystem timestamp resolution],
 # Default to the worst case.
 am_cv_filesystem_timestamp_resolution=2
 
+# Try to exclude this worst case quickly (in much less than 6 seconds).
+if df . 2>/dev/null > conftest.tdf; then
+  # The first word of the last line is the mount point.
+  am_mountpoint=`sed -n -e '$p' < conftest.tdf | sed -e 's/[[ 	]].*//'`
+  if test -n "$am_mountpoint"; then
+    # Determine the file system mounted at that mount point.
+    mount 2>/dev/null | grep "^$am_mountpoint " > conftest.tmt
+    if grep ' type ' conftest.tmt >/dev/null; then
+      # We could determine the file system. Is it FAT or VFAT?
+      # This file system has different names, depending on the OS:
+      # - Linux: "vfat",
+      # - FreeBSD: "msdosfs",
+      # - macOS, NetBSD, OpenBSD: "msdos",
+      # - Solaris: "pcfs".
+      if grep ' type vfat ' conftest.tmt >/dev/null \
+         || grep ' type msdosfs ' conftest.tmt >/dev/null \
+         || grep ' type msdos ' conftest.tmt >/dev/null \
+         || grep ' type pcfs ' conftest.tmt >/dev/null; then
+        :
+      else
+        # It is not FAT or VFAT.
+        am_cv_filesystem_timestamp_resolution=1
+      fi
+    fi
+  fi
+fi
+if test $am_cv_filesystem_timestamp_resolution = 2; then
+  am_try_resolutions=1
+else
+  am_try_resolutions=
+fi
 # Only try to go finer than 1s if sleep can do it.
-am_try_resolutions=1
 if $am_cv_sleep_fractional_seconds; then
   # Even a millisecond often causes a bunch of false positives,
   # so just try a hundredth of a second. The time saved between .001 and
-- 
2.34.1