On Sat, Sep 5, 2020 at 4:18 PM Sidney Cadot <sidney.ca...@gmail.com> wrote: > (As an aside: I was surprised to see the number of processes that > were started even when just doing a “./configure --help” (36 in all, > including stuff like ‘rm', ‘mkdir', ‘chown’, and ‘ln’). To someone > like me who is not familiar with the inner workings of autoconf, > this looks quite excessive for a command invocation that emits some > help text to stdout.)
This has been improved since 2.69 but there is still a bunch of unnecessary work being done. If you're curious, it is probing for how to avoid portability gotchas in various shell utilities that any given configure script may or may not actually need. Ideally this would happen *after* we know we are not just going to print the help and exit, and it would happen only if the script genuinely needs the utility in question. We are trying to get 2.70 out the door right now and this part of the code is very fragile, so we wouldn't *take* any patches until after the release, but if you were interested in working on speeding up configure script initialization (or speeding up configure scripts in general), we would like to *see* your patches. ;-) > The problem is not unique to sed, it was just one of the smallest > packages to demonstrate it. Of the dozen or so packages I tested, > sed-4.8, diffutils-3.7, and grep-3.4 showed this behavior, but there > are probably others. Sad but unsurprising - any configure script that was generated by a development version of Autoconf dated since 2013(!) and prior to March of this year(!!) will have the bug. The lesson for us is, we need to do releases more often, and we need to test our code better. :-/ zw
