Re: Selecting a C++ standard

[Dave Goodell]

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