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

[Jim Meyering]

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.