[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: Zack Weinberg
Subject: Re: M4sh tests 77 and 78 vs /bin/sh -> dash
Date: Mon, 23 Mar 2020 16:20:05 -0400

On Mon, Mar 23, 2020 at 3:48 PM Bob Friesenhahn
<address@hidden> wrote:
> On Mon, 23 Mar 2020, Zack Weinberg wrote:
> >
> > Given that Debian is _deliberately_ configuring dash without LINENO
> > support in order to work around configure scripts containing bashisms,
> > I think we should make changes in this area cautiously and with a lot
> > of public notice.  It's my personal opinion that we should push
> > configure-script authors in the direction of not using bash
> > extensions, maybe even at the expense of performance.
> In my experience, bash is so popular as a command-line shell (and
> sometimes/often as a scripting shell) that configure-script authors do
> not know any better.  They are not aware that they are using
> bash-specific syntax since they often do not read documentation and
> just use what appears to work.
> some configure scripts are for convenience rather than portability

I don't doubt you -- but I think Autoconf does not need to cater to
those people.

If you don't need portability, if you just want a build system that
will work on a small number of platforms that you yourself care about,
there's lots of options that are less hassle than Autotools -- I've
had relatively good experiences with Meson, I've also heard good
things about Bazel, and I had _bad_ experiences with CMake but lots of
other people love it so maybe it's just me.  In fact, if you just want
to write _code_ that will work on a small number of platforms that you
yourself care about, I would suggest not writing that code in C

Autotools and C still have their niche, and that niche is code that
_does_ need to be extremely cross platform.  That means future
development of Autoconf should prioritize the needs of developers
working on that kind of code.  And I think one of the things those
developers want is to be informed as soon as possible when their
configure script is not as portable as it could be; which means, among
other things, avoiding running it with bash or zsh unless no other
option is available.


reply via email to

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