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

[Adrian Bunk]

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.


> 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.

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?

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.


>...
> Regards,
>   Stefano

cu
Adrian

[1] unlikely, but not completely impossible

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed