libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CONFIG_SHELL and `./config.status --recheck'


From: Ralf Wildenhues
Subject: Re: CONFIG_SHELL and `./config.status --recheck'
Date: Wed, 9 Nov 2005 22:30:10 +0100
User-agent: Mutt/1.5.9i

Hi Paul,

* Paul Eggert wrote on Mon, Nov 07, 2005 at 03:11:26AM CET:
> Ralf Wildenhues <address@hidden> writes:
> 
> > One possibility would be to restart once with /bin/sh, or, if part of
> > the environment, with CONFIG_SHELL, or, after parsing the command line,
> > with CONFIG_SHELL, if that is given there.  All of this is very slow
> > (read: dog-slow), and I'd really like to avoid another restart if at all
> > possible.
> 
> I didn't quite follow all that, but don't you have to restart once
> anyway, on Solaris, if the user just does ./configure?

Yes.

> Can't we figure out before restarting the first time, what should be
> in the environment for the second time?  Then we'd need only one
> restart.

I believe so.  In any case I am not discussing the restart that happens
upon manual configure.  It's fine.  It can be avoided by

  CONFIG_SHELL=/good/shell /good/shell configure [...]

> I assume you're trying to avoid the need for _two_ restarts, which
> is understandable.

Well, yes: I am trying to avoid the need for (two) restarts upon
`./config.status --recheck'-induced reruns of configure.
Current ways only need one restart, but have a bug, as outlined.

> > Another possibility would be to test for an external echo program first,
> 
> I'd rather not do that; it's pretty slow.

ACK.

I believe above could work with two changes: Autoconf should recommend
passing CONFIG_SHELL as environment variable (as opposed to: as option
to configure), so it's available to the shell selection mechanism,
which runs before the argument parsing is done.  Also, config.status
should set it for configure reruns.  Both are done in the patch below.

Note that _AS_DETECT_BETTER_SHELL itself (which is also expanded before
the argument parsing loop) reads $CONFIG_SHELL as well.  I'm not sure
whether it was deliberate that it would not see this variable upon the
recheck.

OTOH, setting CONFIG_SHELL upon `./config.status --recheck' makes a
certain assumption: that the shell does not change.  Or, for example,
the PATH, should the user not have used an absolute path as in
  CONFIG_SHELL=bash bash configure
I'm not so sure whether this assumption is safe to make; we might want
to discourage non-absolute names.

What do you think?  The patch below appears to fix the issue on Solaris.

(Another possibility would be to recheck with /bin/sh and not set
CONFIG_STATUS, iff the user did not set this either (and we can find out
about this reliably); a bit safer.)

Cheers,
Ralf

        * lib/autoconf/status.m4 (_AC_OUTPUT_CONFIG_STATUS): Pass
        CONFIG_SHELL in the environment of the configure rerun.
        * doc/autoconf.texi (Here-Documents, config.status Invocation):
        Suggest passing CONFIG_SHELL absolute, and in the environment
        rather than as option.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.932
diff -u -r1.932 autoconf.texi
--- doc/autoconf.texi   21 Oct 2005 05:46:50 -0000      1.932
+++ doc/autoconf.texi   9 Nov 2005 21:18:44 -0000
@@ -9958,8 +9960,8 @@
 version M-12/28/93d, mishandles variable expansion that occurs on
 1024-byte buffer boundaries within a here-document.  Users can generally
 fix these problems by using a faster or more reliable shell, e.g., by
-using the command @samp{bash ./configure CONFIG_SHELL=bash} rather than
-plain @samp{./configure}.
+using the command @samp{CONFIG_SHELL=/bin/bash /bin/bash ./configure} rather
+than plain @samp{./configure}.
 
 Some shells can be extremely inefficient when there are a lot of
 here-documents inside a single statement.  For instance if your
@@ -14149,9 +14151,9 @@
 option.  It must be Bourne-compatible.  The default is a shell that
 supports @code{LINENO} if available, and @file{/bin/sh} otherwise.
 Invoking @command{configure} by hand bypasses this setting, so you may
-need to use a command like @samp{/bin/bash ./configure
-CONFIG_SHELL=/bin/bash} to insure that the same shell is used
-everywhere.
+need to use a command like @samp{CONFIG_SHELL=/bin/bash /bin/bash ./configure}
+to insure that the same shell is used everywhere.  The absolute name of the
+shell should be passed.
 @end defvar
 
 @defvar CONFIG_STATUS
Index: lib/autoconf/status.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/status.m4,v
retrieving revision 1.77
diff -u -r1.77 status.m4
--- lib/autoconf/status.m4      21 Oct 2005 07:36:32 -0000      1.77
+++ lib/autoconf/status.m4      8 Nov 2005 07:06:21 -0000
@@ -1256,8 +1261,8 @@
 _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF
 if \$ac_cs_recheck; then
-  echo "running $SHELL $[0] " $ac_configure_args \$ac_configure_extra_args " 
--no-create --no-recursion" >&AS_MESSAGE_FD
-  exec $SHELL $[0] $ac_configure_args \$ac_configure_extra_args --no-create 
--no-recursion
+  echo "running CONFIG_SHELL=$SHELL $SHELL $[0] " $ac_configure_args 
\$ac_configure_extra_args " --no-create --no-recursion" >&AS_MESSAGE_FD
+  CONFIG_SHELL=$SHELL exec $SHELL $[0] $ac_configure_args 
\$ac_configure_extra_args --no-create --no-recursion
 fi
 m4_ifdef([_AC_OUTPUT_COMMANDS_INIT],
 [#




reply via email to

[Prev in Thread] Current Thread [Next in Thread]