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. 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. Best, Karl