Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell

[Stefano Lattarini]

On 11/10/2012 11:22 AM, Adrian Bunk wrote:
> On Sat, Nov 10, 2012 at 10:00:17AM +0100, Stefano Lattarini wrote:
>> On 11/10/2012 01:45 AM, Eric Blake wrote:
>>>
>>> [SNIP]
>>>
>>> What I'm thinking right now (but don't have the patch ready yet) is that
>>> we will reinstate a spy that loudly warns if autoconf can't find a POSIX
>>> shell, with a request for bug reports, and in parallel add a new macro
>>> (maybe named AS_SHELL_POSIX) that other packages can use to require a
>>> POSIX shell even with autoconf 2.70.  That is, using the new macro would
>>> switch autoconf from spying to requiring POSIX, but packages that aren't
>>> ready to require POSIX can still safely use 2.70, and the spy will help
>>> us know if anyone is really stuck on a non-museum system where it matters.
>>>
>> This is a good idea.  It might also scale well in case we'll decide to
>> allow the user to request more POSIX or not-so-POSIX features from the
>> shell: that could be implemented with a similar macro AS_SHELL_EXTRA
>> (say), or, for finer control and granularity, by having AS_SHELL_POSIX
>> take arguments specifying extra suggested or required features:
>>
>>     AS_SHELL_POSIX([
>>        set-x-dont-corrupt-stderr=suggested
>>        set-e-respects-exit-traps=required
>>     ])
> 
> I'm a bit worried about the direction this discussion is taking,
> IMHO adding AS_SHELL_POSIX would be a mistake.
> 
> The purpose should be to make software portable to as many systems as 
> possible, not making it easy to exclude systems.
>
Sorry, but I don't believe that it's acceptable to burden the maintainers
with lot of extra works and the modern systems with extra run-time or
build-time costs just to make file easier on the 0.001% percent of museum
systems still in use.

> And the absolute worst case would be if automake would *ever*
> use AS_SHELL_POSIX - that would completely defeat the purpose
> of having it optional.
>
Trying to write code portable to non-POSIX Bourne shells is no longer,
by a any stretch and in any measure, a productive use of our time.

In Automake 1.14, I *will* require a POSIX shell.  If Autoconf provides
means to do so, I'll happily and gratefully use them.  Otherwise, I'll
implement them myself in AM_INIT_AUTOMAKE.  This is not a move that I'll
take lightly, since I know the mess this attitude of "Autoconf doesn't
provide what it should, just implement it in Automake instead" has
caused in the past (with lots of bad effects still rippling though
the current code base and development process).  But I strongly believe
it's time the Autotools move in the new century, instead of remaining
stuck in the eighties or the nineties.

> If it turns out that there are still systems that only have a 
> not-so-POSIX shell, then whatever features are missing on such
> systems must not be used.
>
I mostly agree on this.  But that should only concern the *default*
of AS_SHELL_POSIX: that is, if the only POSIX shells present on (say)
Solaris 10 have a bug that prevent the use of a non-core POSIX
feature, Autoconf should cater to those bugs by not assuming that
feature, and thus not reject those shells by default [1].

 [1] But if that bug is only present on, say, Solaris 8 or
     FreeBSD 3.0, we should happily, deliberately and aggressively
     ignore it.

OTOH, if an Autoconf client package don't care about such extra
portability (e.g., because it only cares about GNU/Linux and BSD
systems), such portability shouldn't be forced down its throat:
the package authorsshould have a way to ask to autoconf to reject
the shells that doesn't conform to their expectation.

> Add a "spy that loudly warns" into autoconf 2.70 and wait 6-12 months
> for the results. Then we'll know what features can safely be assumed
> to be present on all systems.
> 
I can do this as well, especially because I don't see Automake 1.14
appearing before six or eight months anyway.  So we might agree on
the roadmap in the end, albeit we'll agree to disagree on the other
details.

Thanks,
  Stefano