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

[Stefano Lattarini]

On 11/10/2012 02:58 PM, Adrian Bunk wrote:
> On Sat, Nov 10, 2012 at 02:07:38PM +0100, Stefano Lattarini wrote:
>> 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.
> 
> 
> With all that gets blamed (sometimes rightfully and sometimes wrongly)
> on autoconf/automake/libtool, portability was so far always a plus point.
>
True, but "portability" != "maximum portability".  The benefits of the
first still outweight its costs; this is not true for the second IMHO.

> 
>> 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).
> 
> K&R compilers are no longer supported.
>
You are not referring to the modern Sun C compilers (those from
Sun Studio), right?  Because I can assure you there is nothing "K&R"
about them ;-)

> gcc 2.95 on Solaris 7 is likely no longer used.
> 
> But I just read the "Shell Substitutions" section of the autoconf info 
> page, and according to that the last stable version of pdksh has shell 
> substitution bugs.
>
> Are the relevant patches in all pdksh binaries used today?
>
Please understand I'm not proposing to reject a shell just because it has
a bug in some tricky corner case...  Otherwise, we should reject Bash and
dash as well :-)  We should manage to strike a balance between catering to
"reasonable" shell bugs [1] and avoid getting bogged down trying to cater
to every brain-dead shell out there (I'm looking at you, Solaris /bin/sh).
That won't be trivial, but we have to try (and have to do so ASAP, IMHO).

  [1] Example of such a bug: "unset" on an already unset variable return
      a non-zero exit status on older bash, NetBSD /bin/sh, and Solaris
      ksh.

> If we would e.g. end up with GNU software no longer compiling on a still 
> used OpenBSD release [1] that would be a bad thing.
>
Agreed.

Regards,
  Stefano