automake-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[automake-commit] branch master updated: automake: a millisecond is too


From: Karl Berry
Subject: [automake-commit] branch master updated: automake: a millisecond is too fast for subsecond-mtime.
Date: Wed, 17 Jan 2024 12:51:51 -0500

This is an automated email from the git hooks/post-receive script.

karl pushed a commit to branch master
in repository automake.

View the commit online:
https://git.savannah.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=22ecc131cd36d0725acf6ef801d963aeada531a3

The following commit(s) were added to refs/heads/master by this push:
     new 22ecc131c automake: a millisecond is too fast for subsecond-mtime.
22ecc131c is described below

commit 22ecc131cd36d0725acf6ef801d963aeada531a3
Author: Karl Berry <karl@freefriends.org>
AuthorDate: Wed Jan 17 09:51:40 2024 -0800

    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.
---
 m4/sanity.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]