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

Jacob Bachmeyer <[email protected]> Tue, 18 Jun 2024 21:30:42 -0500
Newsgroups gmane.comp.sysutils.automake.general
Message-ID <[email protected]>
Zack Weinberg wrote:
> On Tue, Jun 18, 2024, at 12:02 AM, Jacob Bachmeyer wrote:
>   
>> [...]
>> 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.
>>     
>
> In my experience, tarballs cannot be trusted to get this right, *and*
> tar implementations cannot be trusted to unpack them accurately
> (e.g. despite POSIX I have run into implementations that defaulted to
> the equivalent of GNU tar's --touch mode).  Subsequent bounces through
> downstream repackaging do not help.   Literally as I type this I am
> watching gettext 0.22 run its ridiculous number of configure scripts a
> second time from inside `make`.
>   
First, "make dist" should get the tarball right.  Second, absent some 
special flag (--enable-maintainer-mode?), a package using Automake 
should have no problem if all distributed files have the same timestamp.

I see a possibility of a lazy tar(1) implementation not restoring 
timestamps at all, with the result that the unpacked files get mtimes in 
the order they were unpacked from the archive.  Perhaps "make dist" 
should sort the files into the proper order while packing the tarball?  
Automake should have the dependency graph available while generating the 
"make dist" commands...

>> Does "make dist" need to touch configure to ensure that it is newer
>> than its dependencies before rolling the tarball?
>>     
>
> It ought to, but I don't think that will be more than a marginal
> improvement, and touching the top-level configure won't be enough,
> you'd need to do a full topological sort on the dependency graph
> leading into every configure + every Makefile.in + every other
> generated-but-shipped file and make sure that each tier of generated
> files is newer than its inputs.
>
> I wonder if a more effective approach would be to disable the rules to
> regenerate configure, Makefile.in, etc. unless either --enable-maintainer-mode
> or we detect that we are building out of a VCS checkout.

I thought that that /was/ the effect of --enable-maintainer-mode?  I 
would also suggest not handling VCS checkouts specially.  If you want 
the Makefile rules for generating GNU build system scripts, you should 
have to say --enable-maintainer-mode.  Otherwise, you can always use the 
tools directly or put an autogen.sh or bootstrap.sh or similar in the VCS.


-- Jacob