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

Zack Weinberg wrote:
> On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote:
> ...
>
> Don't have enough brain right now to comment on any of the rest of your suggestions, but:
>
>   
>> once conftest.file is newer than configure, surely 
>> config.status, which is produced after all tests are run, /must/ also be 
>> newer than configure?
>>
>> How is this last check/delay actually necessary?  Are there broken 
>> systems out there that play games with causality?
>>     
>
> I regret to say, yes, there are. For example, this can happen with NFS if there are multiple clients updating the same files and they don't all agree on the current time. Think build farm with several different configurations being built out of the same srcdir - separate build dirs, of course, but that doesn't actually help here since the issue is ensuring the Makefile doesn't think *configure* (not config.status) needs rebuilt.

Wait... all of configure's non-system dependencies are in the release 
tarball and presumably (if "make dist" worked correctly) backdated older 
than configure when the tarball is unpacked.  Does "make dist" need to 
touch configure to ensure that it is newer than its dependencies before 
rolling the tarball?

How can configure [appear to] need to be rebuilt here?  No build should 
touch it or its dependencies.

Or, to put this another way, under what conditions can "checking that 
generated files are newer than configure" actually fail?  If we do not 
know of any, then perhaps we should add a hidden 
"--enable--wait-for-newer-config.status" (double-hyphen intentional) 
option, and unless that option is given, bail out with a message asking 
(1) to report the system and environment configuration to the Automake 
list and (2) rerun configure with that option to sleep until 
config.status is newer instead of bailing out.


-- Jacob