[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell
From: |
Stefano Lattarini |
Subject: |
Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell |
Date: |
Sat, 10 Nov 2012 15:21:52 +0100 |
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
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, (continued)
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Adrian Bunk, 2012/11/07
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Eric Blake, 2012/11/07
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Stefano Lattarini, 2012/11/07
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Eric Blake, 2012/11/09
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Stefano Lattarini, 2012/11/10
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Adrian Bunk, 2012/11/10
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Stefano Lattarini, 2012/11/10
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Adrian Bunk, 2012/11/10
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Stefano Lattarini, 2012/11/10
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Adrian Bunk, 2012/11/10
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell,
Stefano Lattarini <=
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Adrian Bunk, 2012/11/10
- Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell, Stefano Lattarini, 2012/11/10