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

On Mon, Apr 20, 2020 at 6:13 PM Karl Berry <[email protected]> wrote:
>     the command that updates autom4te.cache/traces.0 does not modify
>     configure.ac at the same time.
>
> No argument for that specific case. But looking at the change in
> isolation:
>
> -      if ($mtime < mtime ($dep))
> +      if ($mtime <= mtime ($dep))
>         {
>           verb "up_to_date ($file): outdated: $dep";
>
> it says that a dependency with the same mtime as the target will now be
> "outdated", instead of being up to date. This just seems contrary to the
> standard behavior in make (and wherever else), and what would generally
> be expected.
>
>   998 Autom4te::C4che->load ($icache_file)
>   999   if -f $icache && mtime ($icache) > mtime ($0);
>
> I agree it's inconsistent with the current up_to_date_p.
>
> I understand some change needs to be made for autom4te to work
> consistently with subsecond timestamps. I have no problem with that, but
> autom4te is part of autoconf, not automake, as you know.
>
> So ... the change that comes to my mind is to avoid using up_to_date_p
> in autom4te. There could be a new function, or since it is apparently
> only used at one place (line 923), just write out the mtime tests as
> needed, as you cited above. Seems like the mtime test could be part of
> the   while ($_ = $deps->getline)  loop just above the present call to
> up_to_date_p.

I agree that we should break this dependency: either way would work
for me: new function or inline.

> As for the up_to_date_p function, it is not used in automake at all. As
> far as I can see, it is only used in autom4te.  But perhaps it is used
> entirely outside automake/autoconf by other random (user?) programs.
> I doubt it, but can any of us be sure? And if it does have outside users,
> that would be more reason not to change it. Alternatively, if we're sure
> there are no outside users, my proposal would be to delete it, as unused.

I confess that I like the idea of removing it from automake, since no
search I ran found any other use of it, but that would render the next
automake unusable with any older autoconf that still requires it. We
could of course mandate a newer version of autoconf that doesn't need
it, but even that could probably go awry...

Probably best to leave it, as is, and mark it as known-to-be-unused at
least via comment.
Thanks for working on this.