Subject: Re: [Boost-build] Setting C and C++ standards in Boost.Build
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2014-03-28 16:37:42
On 03/28/2014 08:50 AM, Tom wrote:
> I have been trying to set C and C++ standards more accurately in the
> Boost.Build files for my (non-Boost) project and it seems a bit
> impossible. The problem stems from the fact that each toolset seems
> to deal with C and C++ flags a little differently
That's probably a bug. They should be consistent.
The documented behavior is:
"The value of those features is passed without modification to the
corresponding tools. For cflags that is both the C and C++ compilers,
for cxxflags that is the C++ compiler and for linkflags that is the linker."
> and none seems to do
> it in such a way that I can apply flags to only the C or only the C++
> compiler. So when I try to set the standard to use for C and C++, in
> gcc, for example, both end up appearing on the command line which the
> compiler does not like.
> Up until now, I have been using a project-config.jam in the root of my
> projects to specify <cflags> conditionally on the toolset. For now, I
> just set -ansi and -pedantic in <cflags> and luckily that works for
> C89 and C++98, which are what I have been using across all my
> projects. Unfortunately, I'm trying to update some of my projects to
> C++11 (or at least experiment with it) and I'm not able to just change
> the C++ compiler standard with affecting the C compiler standard.
I believe that <cxxflags> is supposed to work for this.
If cxxflags is applied to c compilation please file
a bug report at http://svn.boost.org for that toolset.
> 1. Add top-level properties that set the standard levels (e.g.,
> <cstd>, <cxxstd>, <objcstd>, <objcxxstd> or some other naming
> I like this the best since it seems to follow the Boost.Build
> paradigm of giving high-level names to properties and applying them
> as each compiler requires. This could even result in a
> understandable error if a particular compiler does not support a
> given standard.
> I think this is a good solution in general, partly because it does
> not have to address the issue of <cflags> vs. <cxxflags>.
This is a good idea, but it's a bit tricky
to get it right, as Boost.Build doesn't have
a way to make the default value of a feature
(<cstd>) depend on the value of another
feature (<toolset>). The easiest way, which
I expect is good enough for most uses is to
make the feature optional and say that a
missing value means to use the compiler's
default. This will mean that you can't write
conditionals like <cxxstd>c++11:<cxxflags>...
Also, how should we deal with the fact that
gcc combines the language standard with
its own extensions in this option (e.g.
-std=gnu++11 vs. -std=c++11)
> 2. Make the existing <cflags> and <cxxflags> apply only to C and C++
> compilers respectively and add a new property for compiler-specific
> flags (something like <compilerflags> from the initialization
> syntax of some compilers).
> This might be good separately since the behavior of <cflags> and
> <cxxflags> is so confusing as it is, but it still likely breaks a
> lot of Boost.Build projects. I would be willing to fix my existing
> projects for something like this, but I would imagine others might
I would really like to be able to do this. Making
cflags apply to C++ was a poor design choice, since
(as you've found) it makes it impossible to apply
flags only to C and not C++. Unfortunately, I don't
think it can be done at this point.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk