Re: another CONFIG_SHELL doc instance missed

[Ralf Wildenhues]

Hi Stepan,

* Stepan Kasal wrote on Fri, Jan 13, 2006 at 05:18:27PM CET:
> On Fri, Jan 13, 2006 at 10:37:09AM +0100, Ralf Wildenhues wrote:
> >         * doc/install.texi (Defining Variables): Put `CONFIG_SHELL'
> >         in environment of `configure', not the command line.
> ...
> > OK to apply?
> 
> a quick answer: why is it necessary to have this?

Because you definitely want the shell searching routine as early as
possible in the configure script: everything before it will possibly be
executed more than once, and thus causes further slowdown.

Furthermore, there are users of CONFIG_SHELL before the parsing loop
within Autoconf itself, it's not just libtool: _AC_INIT_DEFAULTS comes
before _AC_INIT_PARSE_ARGS, even AS_DETECT_SUGGESTED itself does.

I am *really* reluctant to change ordering for several reasons:
- It's pretty easy to get wrong in little-tested situations.
- Other packages outside of Autoconf and Libtool may muck around with
  these undocumented internals.
- To some extent, these initialization issues will always be there;
  this example is a pretty benign one IMVHO.

Please reread all the threads that led to this change, to get $ECHO
detection right in Libtool; I really don't want to have to do it all
again.  :-/

> It seems that the problem could be fixed by inspecting the arguments
> before the echo tests, so that CONFIG_SHELL is set correctly.

I believe the argument inspection is not cheap, it costs several forks
(but have not measured anything, to be honest).

> But I guess that there must be better solution:
> 1) cannot libtool use something like AS_DETECT_SUGGESTED if it is
> going to exec configure under a "better shell"?

Likely yes.  This is a completely orthogonal issue though
(and again, one I'd like to start looking at outside of stable branches
and hopefully stabilizing ones).

> 2) or if the main purpose is to find out a good shell for the libtool
> scripts, perhaps the tests could be performed later...

No.  See above.  We need $ECHO within the configure script already.

> 3) libtool (mis)uses the [NOTICE] divertion from m4sh (which is there
> only because of libtool ;-).  Shouldn't we better specify this
> communication, and find an adequate interface.

Sure.  Same comment as for (1).

> Please don't thing about compatibility with old version for now.
> Let's find a good specification first; then we can do some hacks to
> fix for combinations of different versions.

Stepan, people would like to see new versions of both Autoconf and
Libtool soon.  While not only compatibility is an issue you should *not*
underestimate, also the introduction of new bugs is an issue with more
fundamental changes.  Your ideas were not proposed back when I suggested
moving CONFIG_SHELL to the environment first; now, I don't think it's a
good thing to do before Autoconf-2.60 resp. Libtool-2.0.  This in turn
makes me for one also not want to think about this more, for now at
least; I introduce enough bugs already.

Cheers,
Ralf