bug-autoconf
[Top][All Lists]
Advanced

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

Re: Substitution of SHELL and CONFIG_SHELL


From: Niels Möller
Subject: Re: Substitution of SHELL and CONFIG_SHELL
Date: 10 Feb 2004 09:11:38 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Paul Eggert <address@hidden> writes:

> address@hidden (Niels Möller) writes:

> > I noticed this because only because one user couldn't got bash errors
> > when running make, and it turned out he had a set -u in his .bashrc.
> > To me, doing that unconditionally in .bashrc seems like a very broken
> > thing to do,
> 
> Hmm, wasn't it so broken that it also broke his 'configure' invocations too?

Appearantly not. It was one of automake's *-recursive rule that used
the variable $fail without defining it. configure seems to define all
variables before use.

> Also, perhaps this is more of an Automake issue rather than an
> Autoconf issue?  That is, either the GNU coding standards should be
> changed, or Automake should be changed to output "SHELL = /bin/sh"
> rather than "SHELL = @SHELL@" into Makefile.in.  (Or perhaps it should
> be changed to "SHELL = @MAKE_SHELL@" so that we could distinguish the
> two uses of shells.)

What else is SHELL used for in autoconf? I thought substution into
Makefile was the main point of that variable.

Browsing the generated configure, it seems that besides substitution
into output files, SHELL is used for invocations of configure (in
subdirectories), config.guess, config.sub, and when testing for
automake's missing and depcomp scripts. To me, it would make more
sense to use CONFIG_SHELL when invoking configure and config.*.

Anyway, I think address@hidden@ would be nice. MAKE_SHELL should be
set to /bin/sh except under very special circumstances, like if the
user explicitly setts MAKE_SHELL on the command line, or if configure
finds that /bin/sh really is too broken to be able to execute make
rules.

And hard coding SHELL=/bin/sh in Makefile.in seems like a step
backwards.

Regards,
/Niels




reply via email to

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