Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

Karl Berry <[email protected]>
Newsgroups gmane.comp.sysutils.automake.patches,gmane.comp.sysutils.autoconf.bugs
Message-ID <[email protected]>
    Probably best to leave it, as is, and mark it as known-to-be-unused at
    least via comment.

How does the text below look for an explanation?

(By the way, I noticed that FileUtils.pm, unlike the other *.pm in
lib/Automake, doesn't have an =over 4 ... =back around all the other
items, causing pod2text to complain. I'll fix that too unless there is
some magical reason for it.)

--- a/lib/Automake/FileUtils.pm
+++ b/lib/Automake/FileUtils.pm
@@ -181,7 +181,20 @@ sub update_file ($$;$)
 
 =item C<up_to_date_p ($file, @dep)>
 
-Is C<$file> more recent than C<@dep>?
+Is C<$file> strictly more recent than C<@dep>?
+If mtimes are equal, returns true.
+
+This function is not used anywhere in Automake.  Where it is used is in
+C<autom4te>, which is part of Autoconf.  And its use there poses a
+problem with respect to subsecond timestamps, as discussed at
+L<https://lists.gnu.org/archive/html/automake-patches/2020-04/msg00000.html>
+(thread continues into May).  The best approach seems to be to leave this
+function alone, and have C<autom4te> use a different test, one which is
+not part of Automake.
+
+Although we would like to remove this function from Automake, since it's
+not used, that would break older versions of Autoconf, which seems
+gratuitious. So we leave it, unchanged.
 
 =cut
 

compile finished at Sat May  9 18:09:15 2020
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.