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