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: 2016-01-04 00:20:18

Tom <tabsoftwareconsulting <at> gmail.com> writes:

> 
> Steven Watanabe <watanabesj <at> gmail.com> writes:
> 
> > On 03/28/2014 08:50 AM, Tom wrote:
> >
> > > <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?
> 

Well, I finally bit the bullet and gave adding a language standard
flag and created a branch on GitHub with the changes and an
issue describing it.  The approach is to define a feature for each
language and implement support in each toolset.  There is more
work to do, but I think it is enough for others to get a sense of how
it might work and review the approach.

In terms of a fall-back approach, I chose the approach to fail (with
a hopefully explanatory compiler error) if the requested standard is
not supported.  I figured that if someone wanted c++14 or c89,
they needed it or wanted it.  This is straightforward to fix, but is
distributed in the many toolset implementations.

If you are interested in this feature, please review it and comment
on the issue.

   https://github.com/boostorg/build/issues/118

Thanks!
Tom