On Jan 10, 2013, at 5:37 PM CST, Paul Eggert wrote: > On 01/10/2013 03:00 PM, Roger Leigh wrote: >> Given in the discussion that examples were provided where selecting >> the latest version was not always a desirable behaviour, > > Sorry, I don't recall the examples. There were some contrived examples, as well as one slightly less contrived one that had to do with enum scoping differences between C89 and C99: http://lists.gnu.org/archive/html/autoconf/2012-10/msg00080.html > Is it likely that that some packages won't want -std=gnu++11, > but other packages will? And perhaps if they use gnulib, it could > be that some directories will want to be compiled with -std=gnu++11 > and other directories won't? I can't speak to this part, as I'm not a gnulib user. >> is providing the macros for specific standards versions still needed? > > I'm hoping the answer is "no" but I may be wrong. It's probably not strictly needed, but it would be extremely useful. And it seems to me that what is definitely needed is the ability to prevent AC_PROG_CC from always selecting the latest version of the language supported by the compiler/environment. For my primary project, MPICH, we operate in two separate modes: A) Development & Testing Mode, where we attempt to build with the compiler set to a fairly conservative language version, such as C89 with a particular (non-recent) version of POSIX. This helps us, as developers, to remember that certain routines/types/constants/etc. were added in C99/C11 or some recent version of POSIX and should not be used unconditionally. It is also helpful for catching certain differences between platforms, such as Linux and OS X. B) User Build Mode, where we generally want the compiler/environment to be in the most permissive, highest functionality mode. Right now we accomplish (A) with a (fairly ugly) autoconf macro [1] when "--enable-strict" is passed to our configure. We don't explicitly attempt (B), such as with AC_PROG_CC_C99, but we could. It's very important that autoconf does not do anything to the compilation environment that makes (A) more difficult. Otherwise the only way to test our code for reasonably-strict C89/C99 compliance is to keep old machines running old/broken software around forever. That or fight a continuous losing battle trying to hack around autoconf behavior... -Dave [1] http://git.mpich.org/mpich.git/blob/e7fe097dbecee3075869348594fbe2fd8dce5c05:/confdb/aclocal_cc.m4#l417 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
