Subject: [Boost-build] Setting C and C++ standards in Boost.Build
From: Tom (tabsoftwareconsulting_at_[hidden])
Date: 2014-03-28 11:50:08
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 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.
Since there are C and C++ files in this project, I end up with errors
from the C compiler when passing -std=c++98. I'd rather not attempt
to compile the existing C code with a C++11 compiler. There's another
issue in that I want to use a compiler that I've never used before, I
have to add the proper flags to my project-config.jam. This is not
too big a deal, but would be nice to avoid (or be able to set it on
the b2 command line for quick tests across all standards).
Am I missing something or is this what others believe is true as well?
I did spend some time looking through Boost.Build to see if there were
a way to fix this, but I think the changes are probably controversial
since projects are likely to break if the semantics of <cflags> and
<cxxflags> are changed.
I could see several approaches to addressing this. I'm sure there are
some better ideas out there, but I thought these were reasonable to
get the ball rolling.
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
I think this is a good solution in general, partly because it does
not have to address the issue of <cflags> vs. <cxxflags>.
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
3. Introduce new flags properties for C-, C++-, Objective-C-, and
This seems extremely confusing and pretty ugly, but at least would
not break existing Boost.Build files. I don't have a proposal for
naming of something like this.
I suppose all of this probably is applicable to both Objective-C and
Objective-C++ (and whatever other C family dialects are supported).
I'm a big fan of Boost.Build and I have been using it on many complex
production-quality systems for many years. Thanks for all the hard
work and continuing improvements. I would be willing to give this a
try if others with more knowledge do not have time. I think the main
issue I would have beyond understanding how all the toolsets are
designed, is testing changes against all existing compilers.
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