[Top][All Lists]

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

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

From: Bob Friesenhahn
Subject: Re: M4sh tests 77 and 78 vs /bin/sh -> dash
Date: Thu, 12 Mar 2020 11:11:58 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Thu, 12 Mar 2020, Zack Weinberg wrote:

does not, assuming the stock `autoreconf` is from Autoconf 2.69.
This is because `make check` in this sequence re-runs configure
via `config.status --recheck`, which doesn’t recalculate *everything*.
In particular, the value of @SHELL@ will remain at whatever the first
run of ./configure picked.  @SHELL@ controls which shell is used to
run tests/testsuite from `make check`.  And, on a system where /bin/sh
is dash (and /bin/bash also exists), autoconf 2.69’s
`_AS_DETECT_BETTER_SHELL` picks /bin/bash for @SHELL@,
but autoconf trunk’s `_AS_DETECT_BETTER_SHELL` picks /bin/sh.

It would be useful if Autoconf does not require bash. If it requires bash and can not work with a reasonably POSIX-conformant shell (perhaps even ash/dash, bosh, or ksh), then there is a problem. The automatic use of bash is a crutch which may be hiding problems.

This is a reason why verifying that Debian or Gentoo packages build with the new Autoconf does not verify that Autoconf is "ok".

In the past, when it was thought that libtool was feature complete and about ready for release it was then discovered that many non-portable artifacts had crept in and libtool was not ok on non-GNU/Linux systems until those non-portable artifacts were fixed.

If Autoconf were to reqire GNU bash and GNU sed, and Automake were to require GNU make, and libtool were to require GNU binutils and GCC, then Autotools should become a historical artifact.

Bob Friesenhahn
GraphicsMagick Maintainer,
Public Key,

reply via email to

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