Re: 1.16.90 regression: configure now takes 7 seconds to start

[Jacob Bachmeyer]

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 (<vapier@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