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

[Stefano Lattarini]

On 11/10/2012 01:40 PM, Adrian Bunk wrote:
> On Sat, Nov 10, 2012 at 12:19:05PM +0100, Stefano Lattarini wrote:
>> On 11/10/2012 11:22 AM, Adrian Bunk wrote:
>> ...
>>> 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.
> 
> 
> You miss the main problem here.
> 
> The main problem is not whether the check is in autoconf or in automake.
> 
> The main problem is that this might result in people wanting to have 
> their software running on as many systems as possible locked into
> using old versions of automake and/or autoconf.
> 
> Maximum portability is the main feature of autoconf/automake/libtool.
>
That might have been a killer feature fifteen years ago, but I'm not
sure it is so relevant today.

Being able to seamlessly work with Clang on Mac OS X as well as with
the Sun C compiler on Solaris 10 is important.  Being able to work
with gcc 2.95 on a Solaris 7 system is irrelevant (at least if the
Autotools want to remain mainly concerned up with the GNU philosophy
of promoting software freedom in a practical way).

>
>> 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.
> 
> I'm a fan of getting the data before making the decision.
> 
> Are you committing to undo all these changes in automake if it turns out 
> it causes trouble on some semi-obscure-but-still-used system?
>
> My fear is that you won't, and that you might prefer forcing no longer 
> supporting such systems upon everyone over reverting the changes in 
> automake is my main worry.
>
And I have to say you are spot-on on this: I will require a POSIX shell
in Automake 1.14, period (unless I'm kicked out of maintenance, that
is ;-).  My "wait and see" was only meant as a "wait and see if that
can be enforced in Autoconf as well, before starting duplicated work in
Automake".  Sorry for not making it clearer up-front.

Regards,
  Stefano