[Top][All Lists]

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

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

From: Karl Berry
Subject: Re: [PATCH] up_to_date_p: treat equal mtime as outdated.
Date: Mon, 20 Apr 2020 19:12:31 -0600

    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

-      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

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.


reply via email to

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