Re: Automake 1.8.3 doesn't build?

[Eric Sunshine]

On Mon, 19 Apr 2004 21:01:58 +0200, Alexandre Duret-Lutz wrote:
> 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?

Reverting to a state where SHELL is hard-coded as /bin/sh does indeed seem  
undesirable. As Richard Dawe points out, DJGPP would not benefit from a  
reversion to /bin/sh; and, in general, the flexibility of an Autoconf  
substitution just makes more sense.

> 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).

It is sometimes the case when transporting code between platforms that a  
script's execute status gets lost, which causes the script to fail when it is  
"run" directly. The $(SHELL) indirection works in all cases, regardless of  
the script's execute permission. I work on projects, for instance, which are  
developed heavily by Unix and Windows users. When Windows users create new  
scripts and commit them to a CVS repository, very often, they do not have the  
execute bit enabled. By employing the $(SHELL) indirection when running the  
scripts, we avoid what would otherwise be a fatal problem caused by the  
missing executable status. I would think that the aforementioned invocation  
of install-sh should be upgraded to also employ the $(SHELL) indirection.

> 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.

The patch which I submitted to autoconf-patches yesterday will at least make  
it much, much less likely for zsh to be chosen.

> 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.

I'm not quite sure why CONFIG_SHELL is even being exported from configure.  
My understanding of CONFIG_SHELL is that it is an implementation detail of  
configure itself which should never have escaped to the outside world.  
CONFIG_SHELL is a flag used internally by configure to tell itself that it  
does not have to re-perform the preferred-shell search when it re-runs itself  
after finding a preferred 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.

This is an interesting idea, and Paolo's generic shell testing and selection  
code in Autoconf CVS is just about able to handle this additional  
requirement. (The only hitch is that his code presently invokes  
_AS_BOURNE_COMPATIBLE when testing each candidate shell, but with a little  
re-factoring, invocation of that macro could become optional, thus making it  
possible to detect a shell which does not require it.) This raises the  
question of what constitutes a POSIX-compliant shell (at least in terms of  
what Autoconf and Automake expect), and how does one test for those features?  
The shell's "split" behavior is one obvious case, but what are the others  
(if any)?

> CONFIG_SHELL would allow shell that require such extra code.

I'm not sure that I see the point to this. If a POSIX-compliant shell is  
discovered which is suitable for Automake's needs, then the same shell will  
be suitable for Autoconf, so why make a distinction? It is true that Autoconf  
contains compatibility code to deal with less capable shells, and can safely  
fall back to using even very crippled shells, but I don't see the benefit of  
making a distinction between a shell suitable for Automake and one suitable  
for Autoconf.

> 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"
> and I doubt these will enjoy zsh.

I am wondering if this discussion about SHELL vs. CONFIG_SHELL vs.  
MAKE_SHELL is actually obscuring a more basic issue. It is, of course, a  
reasonable idea to search out and utilize the most capable shell available,  
but, just because a search for a capable shell is performed, does not mean  
that such a shell will be found.

Therefore, the real question, I believe, is one of just how  
backward-compatible the various tools choose to be. Autoconf opts for extreme  
backward-compatible. It accomplishes this by employing numerous  
compatibility and emulation strategies which allow it to continue functioning  
even when faced with a severely crippled shell. Other tools which desire to  
achieve this same level of backward compatibility will need to employ the  
same strategies used by Autoconf. It is not sufficient for a tool merely to  
expect Autoconf to find a capable shell for the tool's use; such a shell  
might not be available.

The upshot is that each tool which desires a high degree of  
backward-compatibility with older shells must actively achieve that  
compatibility itself; it can not rely upon Autoconf to _always_ find a highly  
capable shell.

However, since Autoconf is performing the shell search, and it is  
determining precisely which compatibility strategies to apply, then it is in  
a very good position to export this information for use by other tools. By  
doing so, Autoconf can enable other tools, such as Automake, to take  
advantage of the same strategies which Autoconf has already deemed necessary.  
 Autoconf could, for example, publish a macro such as the following:

AS_SELECT_SHELL([features], [action-if-found], [action-if-not-found])

The optional features argument is lists of well-known shell capabilities for  
which Autoconf knows how to check, and which it possibly knows how to  
emulate if the desired features can not be found in any available shell.  
Obvious features which might be requested are "functions" and "lineno"; other  
desired feature tests (and emulations) can also be added. If able to satisfy  
the feature requests (either by finding a shell which supports them, or via  
emulation), this macro would then export a SHELL variable which (one way or  
another) provides an invocation environment capable of supporting the desired  
features. If no features are requested, then the macro would simply try to  
find a shell which seems to be Bourne compatible (or one which it can  
influence into being Bourne compatible).

As an example, if zsh is the only shell available, the output of this macro  
would be to assign SHELL the value "zsh", plus all the _AS_BOURNE_COMPATIBLE  
goop needed to make zsh act like a Bourne shell. Tools, such as Automake,  
which utilize this macro would then receive a SHELL substitution which is  
capable of producing the expected shell execution environment.

-- ES