Re: [Boost-build] Setting C and C++ standards in Boost.Build

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

AMDG

On 03/28/2014 08:50 AM, Tom wrote:
> Hi,
> 
> 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.

> <snip>
> 1. Add top-level properties that set the standard levels (e.g.,
>    <cstd>, <cxxstd>, <objcstd>, <objcxxstd> or some other naming
>    convention).
> 
>    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
>    not.
> 

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.

In Christ,
Steven Watanabe