Karl Berry wrote:
Find here attached a revised proposed patch.
Ok on the reorg, but sorry, I remain confused. This whole thing started
with Mike Vapier's change in Feb 2022 (commit 720a11531):
https://lists.gnu.org/archive/html/automake-commit/2022-02/msg00009.html
As I read it now, his goal was to speed up other projects, not Automake,
by reducing the "sleep 1" to "sleep <mtime_resolution>" in
AM_SANITY_CHECK, via AC_CONFIG_COMMANDS_PRE, i.e., before creating
config.status.
But that is only one instance of generating files. I must be missing
something obvious. There are zillions of generated files in the
world. For instance, why aren't there problems when a small C file is
created and compiled? That could easily take less than 1 second, if that
is the mtime resolution.
I understand that equal timestamps are considered up to date, and
presumably the .c and .o (say) would be equal in such a case. Ok, but
then why is configure generating config.status/etc. such a special case
that it requires the sleep, and nothing else? I mean, I know the sleep
is needed; I've experienced the problems without that sleep myself. But
I don't understand why it's the only place (in normal compilations;
forget the Automake test suite specifically) that needs it.
The sleep appears to have been introduced in commit
333c18a898e9042938be0e5709ec46ff0ead0797, which also added an item in NEWS:
8<------
* Miscellaneous changes:
- Automake's early configure-time sanity check now tries to avoid sleeping
for a second, which slowed down cached configure runs noticeably. In that
case, it will check back at the end of the configure script to ensure that
at least one second has passed, to avoid time stamp issues with makefile
rules rerunning autotools programs.
8<------
Mike Frysinger (<vap...@gentoo.org>) then complained that the above
change, which enacted a policy of ensuring that any configure run
requires at least one second, significantly delayed building packages
that use many small configure scripts; his example in commit
720a1153134b833de9298927a432b4ea266216fb showed an elimination of nearly
two minutes of useless delays. He appears to have also been trying to
improve the performance of such a package in commit
be55eaaa0bae0d6def92d5720b0e81f1d21a9db2, which may have actually made
the problem worse by changing the test that determines whether to sleep
at all.
I think we might best be able to avoid this by using
AC_CONFIG_COMMANDS_POST to touch config.status if neccessary, instead of
trying to decide whether to sleep before writing config.status.
Can someone please educate me as to what is really going on underneath
all this endless agonizing tweaking of the mtime tests?
I think that the main problem is that the test itself is difficult to do
portably.
-- Jacob
