Re: Automake 1.8.3 doesn't build?

[Alexandre Duret-Lutz]

>>> "Eric" == Eric Sunshine <address@hidden> writes:

[...]

 Eric> I can submit a patch to autoconf-patches to make
 Eric> Autoconf's shell selection more backward-compatible with
 Eric> earlier versions of Autoconf, however this raises another
 Eric> issue. My interpretation of this thread is that
 Eric> Autoconf's new shell selection behavior is exposing a
 Eric> latent problem with Automake; specifically,
 Eric> Automake-generated makefiles do not deal with zsh in a
 Eric> robust fashion. Even after patching Autoconf, it will
 Eric> still be possible for zsh to be the chosen shell (it just
 Eric> won't be as likely), so this same problem can continue to
 Eric> affect Automake. Furthermore, it does not really seem
 Eric> like Autoconf's responsibility to work around a
 Eric> shortcoming in Automake. After all, Autoconf has long
 Eric> considered zsh an acceptable shell (otherwise, those zsh
 Eric> work-arounds would not be present in Autoconf), so one
 Eric> might expect Automake to also consider zsh a usable shell
 Eric> (by employing the same zsh goop, for instance).

This discussion rejoins
http://sources.redhat.com/ml/bug-automake/2004/msg00096.html

A suggestion was to always use `SHELL = /bin/sh' in Makefiles.
I simply don't know how correct this is, because that's how it
was in the past before Chris Provenzano changed it to what it is
now.  The reason for that change seems to have been lost.
Because Chris had a cygnus email address it could be a cygwin
singularity?  Maybe it's for systems that do not have /bin/sh?

In automake Makefiles, most auxiliary scripts like depcomp,
missing, etc. are run as an argument of $(SHELL).  A few are run
directly (e.g., install-sh), go figure why.  Since all of them
are executable, start with `#!/bin/sh', and require only basic
shell features, I wonder why we bother running them we $(SHELL).

Obviously when $(SHELL) is Zsh most of these scripts will break
with unsplit variable symptoms.  Unless we equip these scripts
(and many Makefile rules) with the _AS_BOURNE_COMPATIBLE code.

Regarding the aforementioned thread, I'm not really fond of the
proposal to introduce a MAKE_SHELL variable and use
  SHELL = @MAKE_SHELL@
because in order to access the CONFIG_SHELL variable set
at configure time we would have to use
  CONFIG_SHELL = @SHELL@
creating a spaghetti plate of variables definitions.

If two variables are needed, it would seems neater to use SHELL
for what it was initially introduced: a substitution for the
Makefile's SHELL, and AC_SUBST CONFIG_SHELL on its own.

  SHELL = @SHELL@
  CONFIG_SHELL = @CONFIG_SHELL@

This of course assumes we know how to compute @SHELL@, which I
don't :)  If I had to vote for a definition, I'd say it would be
useful that @SHELL@ be the most POSIX compliant shell that does
not require any configuration code (such as
_AS_BOURNE_COMPATIBLE) to work.  CONFIG_SHELL would allow shell
that require such extra code.

Note that the above definition of SHELL would be useful to
configure itself.  For instance it currently runs things like

ac_config_guess="$SHELL $ac_aux_dir/config.guess"
ac_config_sub="$SHELL $ac_aux_dir/config.sub"
ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus configure.

and I doubt these will enjoy zsh.
-- 
Alexandre Duret-Lutz