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
