Re: configure script for GNU sed 4.8 generated by buggy unreleased Autoconf (was re: "configure" tries to execute what seems to be a shell command)

[Zack Weinberg]

On Sat, Sep 5, 2020 at 4:18 PM Sidney Cadot <sidney.cadot@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