autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Selecting a C++ standard


From: Trent Nelson
Subject: Re: Selecting a C++ standard
Date: Mon, 29 Oct 2012 22:50:10 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Oct 27, 2012 at 05:07:04PM -0700, Harlan Stenn wrote:
> Adrian Bunk writes:
> > On Sat, Oct 27, 2012 at 10:47:50PM +0100, Roger Leigh wrote:
> > > Maybe have an optional argument to AC_PROG_CC_STDC to select
> > > the standard e.g.
> > >   AC_PROG_CC_STDC([C99])
> > > ?
> 
> I like this idea.
> 
> > Latest discussion result was that there is no downside of setting the
> > compiler to the highest mode possible.
> 
> Then that discussion was incomplete.
> 
> If I must ensure that a package requires a given "level" of STDC, then
> configure MUST NOT decide any other "level" is OK.
> 
> > And as said above, feature testing is a separate issue.
> 
> that doesn't mean it is by definition OK to ignore this point.
> 
> > > I originally wrote AC_PROC_CC_C99 because it was several years
> > > since GCC supported C99, but there was no portable way to use
> > > C99 features with projects using autoconf unless you added
> > > horrible hacks.  We still have this situation for C++, and it
> > > would be nice to solve it in a similar way to C.  I'm happy to
> > > go with the new approach of a single macro, but I would be
> > > interested to understand how the issues I outlined above square
> > > with this.
> > 
> > The main worry would actually be whether a compiler in C++11 mode might 
> > reject any existing C++03 code.
> 
> I submit you are still ignoring the other side of the problem, which
> says "Make sure I am using a C++03 compiler so I can be sure that the
> package builds with a C++03 compiler if that is all *somebody else* has."

    I think this applies to us in the Python camp.  We use C89,
    basically because that's the lowest common supported standard
    across the board.  This is important to us for Windows and
    MSVC support, as that will regularly balk on non-C89 code.

    So, in our case, we're not really in the position to use the
    autoconf approach of test-for-the-feature-not-the-std-compliance;
    we simply want to balk on non-C89 code on UNIX platforms, so it
    can be fixed before it gets into the tree and breaks on Windows.

        Trent.



reply via email to

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