autoconf
[Top][All Lists]
Advanced

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

Re: FreeBSD /bin/sh with SHELL=.../zsh breaking autoconf ./configure?


From: Ralf Wildenhues
Subject: Re: FreeBSD /bin/sh with SHELL=.../zsh breaking autoconf ./configure?
Date: Sun, 16 Mar 2008 12:32:19 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Hello Mike,

* Mike Meyer wrote on Tue, Mar 11, 2008 at 04:26:31PM CET:
> On Tue, 11 Mar 2008 08:03:55 +0100 Ralf Wildenhues <address@hidden> wrote:
> > 
> > Thanks.  This patch ports Python's makesetup to be usable with zsh, and
> > results in a Makefile identical to one created with bash.  I have not
> > checked whether other shell scripts in the Python package need similar
> > treatment.  Please report this to the Python folks (best if you also
> > mention the CONFIG_SHELL workaround I wrote in the previous mail).
> 
> This isn't a python specific issue; it occurs with other autoconf
> generated configure scripts as well. Python was just the first one I
> noticed.

Have you even tried my patch?

You may argue that Autoconf's configure scripts should not choose zsh at
all because there are so many user scripts which aren't ready to handle
it; or turn that argument around that zsh is so broken as to be unusable
as a sh replacement.

But there are systems where zsh is (or was) the only usable shell.
So Autoconf can't do that easily.

Autoconf does not search for a better shell when the one it's currently
running under is good enough.  FreeBSD sh does not do $LINENO expansion
reliably, which I think is the reason it started the search here.  You
may argue that LINENO expansion is less of a problem for you than zsh's
quirks; that's likely because you don't see the effects of it because
Autoconf works around it (the configure script rewrites itself with
$LINENO expanded).

So the only thing Autoconf could do is somehow favor shells which have
LINENO issues over zsh's issues, which, well, configure doesn't
currently try to detect because it works around them, too (at a lower
cost than self-rewriting).

There's a quick'n'dirty hack to rule out zsh for your system, but first,
the test is for some other zsh deficiency you noted, namely bogus
function support, and second that again will kill support on some other
systems.  See the patch below for this.  Note I *don't* want this
applied to Autoconf.

The Right Thing To Do[tm] here, IMVHO, would be to
- either fix Python (and other packages) the way I described, or
- have Autoconf publicize the _AS_DETECT_REQUIRED interface and let
  packages like Python announce to Autoconf that they are not ready for
  using zsh.

Cheers,
Ralf

2008-03-16  Ralf Wildenhues  <address@hidden>

        * lib/m4sugar/m4sh.m4 (_AS_SHELL_FN_SPY): Require, rather than
        just suggest, decent shell functions, in order to rule out zsh.
        This will however rule out other shells.

diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index 6689e4b..9a7a76a 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -1632,7 +1632,7 @@ m4_define([AS_VAR_POPDEF],
 # This temporary macro checks "in the wild" for shells that do
 # not support shell functions.
 m4_define([_AS_SHELL_FN_SPY],
-[_AS_DETECT_SUGGESTED([_AS_SHELL_FN_WORK])
+[_AS_DETECT_REQUIRED([_AS_SHELL_FN_WORK])
 _AS_RUN([_AS_SHELL_FN_WORK]) || {
   echo No shell found that supports shell functions.
   echo Please tell address@hidden about your system,




reply via email to

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