[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Selecting a C++ standard
From: |
Dave Goodell |
Subject: |
Re: Selecting a C++ standard |
Date: |
Thu, 10 Jan 2013 23:19:58 -0600 |
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