[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] up_to_date_p: treat equal mtime as outdated.
From: |
Jim Meyering |
Subject: |
Re: [PATCH] up_to_date_p: treat equal mtime as outdated. |
Date: |
Sat, 9 May 2020 19:40:28 -0700 |
On Sat, May 9, 2020 at 6:10 PM Karl Berry <address@hidden> wrote:
>
> 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?
Very good! Thanks for dealing with this.
Two suggestions below.
> (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.)
Sounds fine to fix that. Thanks!
> --- 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
Perhaps s/Where it is used is in/However, it @emph{is} used in/
also, s/subsecond/sub-second/ to pacify spell-checkers :-)
> +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.