autoconf-patches
[Top][All Lists]
Advanced

[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: Adrian Bunk
Subject: Re: [PATCH 0/2] First steps in making autoconf ensure a POSIX shell
Date: Sat, 10 Nov 2012 14:40:26 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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.


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


> Thanks,
>   Stefano

cu
Adrian

-- 

       "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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]