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

Subject: Re: [Boost-build] Setting C and C++ standards in Boost.Build
From: Tom (tabsoftwareconsulting_at_[hidden])
Date: 2014-03-28 18:38:45

Steven Watanabe <watanabesj <at> gmail.com> writes:

> 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."

> 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.

Mostly they are consistent, now that I understand the intended behavior.

I've submitted a ticket for the ones that are not consistent with that
(I think there are three) with an example Boost.Build project to show.

   https://svn.boost.org/trac/boost/ticket/9815

> > <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)

The lack of conditionals is a bit of a problem in that users would
probably expect it to work, though other properties don't either.  Is
<stdlib> similar in this regard?

In regards to the multitude of possible standards, I see several
approaches.  We could fall back to the existing flags approach for
those cases (with cstd left empty) or we could just expose all the
possible standards.  I don't think that is all that bad either.  If
not supporting a requested standard is a hard error, then you must
have gnu++98 and the toolset doesn't support it, your code will almost
surely not compile anyway.  If it was a soft error, no standard would
be assigned and the compile would be attempted.  For clang, which
tries to support GCC or MSVC flags, it might actually support what you
need.
 
> > 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.

I suppose if we could come up with a good name we could add a new one
for c-compiler specific flags since cflags is really
c-compiler-family-flags.  I can't think of a good one, cflags would be
so perfect :)  

Tom