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