Description of problem:
Boost-build

Version-Release number of selected component (if applicable):
boost-build-1.53.0-25.el7.noarch

How reproducible:
100% / fairly trivial

Steps to Reproduce:
1. Try to build a project with Jamroot having an element such as <debug-symbols>on
2. Run bjam -d2 (for debug level 2) release install and see if your c++ option of "-g" for debug-symbols gets passed through. (it does not - it does for the linking part but not the compiling options)
3. As a further step -- see if your program's core dump has line numbers (-g would do this).  It does not have line numbers.

Actual results:

Default options for a "bjam release install" or "bjam debug install" no longer translate typical macros appropriately from a project's Jamroot such as "-g" for <debug-symbols>on or "-O3" for <optimization>speed.  

I traced it down to the file /usr/share/boost-build/tools/gcc.jam appearing to have left out several key elements that were in previous versions of boost-build packages gcc.jam files such as the following lines in gcc.jam that are no longer present:

> toolset.flags gcc.compile OPTIONS <optimization>off   : -O0 ;
> toolset.flags gcc.compile OPTIONS <optimization>speed : -O3 ;
> toolset.flags gcc.compile OPTIONS <optimization>space : -Os ;
>
> toolset.flags gcc.compile OPTIONS <inlining>off  : -fno-inline ;
> toolset.flags gcc.compile OPTIONS <inlining>on   : -Wno-inline ;
> toolset.flags gcc.compile OPTIONS <inlining>full : -finline-functions -Wno-inline ;
>
> toolset.flags gcc.compile OPTIONS <warnings>off : -w ;
> toolset.flags gcc.compile OPTIONS <warnings>on  : -Wall ;
> toolset.flags gcc.compile OPTIONS <warnings>all : -Wall -pedantic ;
> toolset.flags gcc.compile OPTIONS <warnings-as-errors>on : -Werror ;
>
> toolset.flags gcc.compile OPTIONS <debug-symbols>on : -g ;
> toolset.flags gcc.compile OPTIONS <profiling>on : -pg ;
> toolset.flags gcc.compile OPTIONS <rtti>off : -fno-rtti ;

Additional info:

Normally perhaps I'd say this is a feature rather than a bug whereby the boost-build package maintainer expects you to use a different macro than previous versions.  But I'm pretty sure it is a bug because of a few things:

1) Almost all the other tools .jam files still have those macro translations spelled out such as the following non-gcc/non-g++ toolsets:

/usr/share/boost-build/tools/clang-darwin.jam:toolset.flags clang-darwin.compile OPTIONS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/clang-linux.jam:toolset.flags clang-linux.compile OPTIONS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/como-linux.jam:flags como-linux CFLAGS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/cray.jam:flags cray.compile OPTIONS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/gcc.py:flags('gcc.compile', 'OPTIONS', ['<optimization>speed'], ['-O3'])

2) Even the gcc.py file (/usr/share/boost-build/tools/gcc.py) still has -O3 translation:

/usr/share/boost-build/tools/gcc.py:flags('gcc.compile', 'OPTIONS', ['<optimization>speed'], ['-O3'])

3) The default boost-build still uses macros like <optimization>speed for release.  Why would the macro be present if it wasn't expected to be translated to a real-world configuration flag like "-O3".

4) Although I noticed this problem when upgrading from a (very old) version of boost, it appears that the newest version of boost does have those macro translations re added again to the gcc.jam file.  (see https://github.com/boostorg/build)  However that newer version appears quite a bit ahead of both the current RHEL7 and the previous super old version I used to use.  So perhaps it is better to specifically patch gcc.jam based on an older working version vs the newest/latest in case something breaks.  (a diff of my old version and the current RHEL7 version only reveals a few minor changes including those macro expansions vs a diff of the latest greatest reveals quite a number of changes)

Possible Solution To Bug:

Please add back in such toolset.flags options in the gcc.jam file.  For now we have to manually add stuff like "<variant>release:<cxxflags>-O3" which is likely not the intention of the boost-build package maintainers.