[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: another CONFIG_SHELL doc instance missed
From: |
Ralf Wildenhues |
Subject: |
Re: another CONFIG_SHELL doc instance missed |
Date: |
Sat, 14 Jan 2006 14:56:32 +0100 |
User-agent: |
Mutt/1.5.9i |
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