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

Subject: [Boost-build] Setting C and C++ standards in Boost.Build
From: Tom (tabsoftwareconsulting_at_[hidden])
Date: 2014-03-28 11:50:08

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

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.

3. Introduce new flags properties for C-, C++-, Objective-C-, and
   Objective-C++-specific flags.

   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.

Thanks,
Tom