From: Karl Berry <karl@freefriends.org>
Date: Wed, 17 Jan 2024 17:51:40 +0000 (-0800)
Subject: automake: a millisecond is too fast for subsecond-mtime.
X-Git-Tag: v1.16.90~27
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=22ecc131cd36d0725acf6ef801d963aeada531a3;p=thirdparty%2Fautomake.git

automake: a millisecond is too fast for subsecond-mtime.

This patch is from https://bugs.gnu.org/68325.

* m4/sanity.m4 (_AM_FILESYSTEM_TIMESTAMP_RESOLUTION): don't try
for a millisecond; make a hundredth of a second the fastest we'll go.

Apparently there are plenty of systems which supposedly support
subsecond-mtimes down to the millisecond and yet randomly
fail parallelized tests. For example:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68119#18
Maybe the tests themselves need fixing. (The ones that run
autotools multiple times in succession.) A work in progress.
---

diff --git a/m4/sanity.m4 b/m4/sanity.m4
index 84fdf2d08..59afa7b15 100644
--- a/m4/sanity.m4
+++ b/m4/sanity.m4
@@ -34,7 +34,7 @@ am_cv_filesystem_timestamp_resolution=2
 # Only try to go finer than 1s if sleep can do it.
 am_try_resolutions=1
 if $am_cv_sleep_fractional_seconds; then
-  am_try_resolutions="0.001 0.01 0.1 $am_try_resolutions"
+  am_try_resolutions="0.01 0.1 $am_try_resolutions"
 fi
 
 # In order to catch current-generation FAT out, we must *modify* files