[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Automake 1.15.1 released
From: |
Warren Young |
Subject: |
Re: GNU Automake 1.15.1 released |
Date: |
Tue, 20 Jun 2017 11:31:02 -0600 |
On Jun 19, 2017, at 2:50 PM, Mathieu Lirzin <address@hidden> wrote:
>
> - Automake-provided scripts and makefile recipes might (finally!)
> start assuming a POSIX shell in Automake 2.0. There still is no
> certainty about this though: we'd first like to wait and see
> whether future Autoconf versions will be enhanced to guarantee
> that such a shell is always found and provided by the checks in
> ./configure.
Please clarify: does this apply to the shell script code written in *.m4 files
included in the output configure script or to shell script code written in the
user’s configure.ac file?
Currently, it’s the end user’s look-out if they do this. What I’m suggesting
is that it is possible for Autoconf to bend over backwards to ensure that the
generated configure script runs under a local POSIX shell, if available,
thereby making possible use of POSIX shell features in end-user macros and such
even on systems where /bin/sh is not a POSIX shell.
As I understand it, the main difficulty here is that the generated configure
script can’t start with anything other than #!/bin/sh for portability. My
suggestion is that one of the first things the generated code do is test
whether it is running under a POSIX shell, and if not, try to find one and
re-exec itself under that shell instead.
It’s generally possible to find a POSIX-compatible shell somewhere on the
system these days if you only look hard enough: /usr/xpg4/bin/sh on old
Solaris, /bin/bash on Linuxes where /bin/sh is pre-POSIX, /usr/bin/ksh on some
SVR4 systems, etc.
Even the shells built into Busybox are fairly POSIX-compliant these days.