Boost logo

Boost-Build :

Subject: Re: [Boost-build] From where do compiler options come ?
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-09-28 15:40:45


On 27-Sep-15 6:38 PM, Edward Diener wrote:
> I am trying to understand from where compilers options come for a particular toolset when running b2.
> I can see the compiler options generated if I add a -d2 switch to a b2 command. That is not a problem. But looking at
> the particular .jam file for a particular toolset I can not understand what causes the options I see on the command line.
> As an example, using the clang-linux.jam file I can see the way in which various features generate compiler options,
> such as:
> toolset.flags clang-linux.compile OPTIONS <warnings>off : -w ;
> toolset.flags clang-linux.compile OPTIONS <warnings>on : -Wall ;
> toolset.flags clang-linux.compile OPTIONS <warnings>all : -Wall -pedantic ;
> toolset.flags clang-linux.compile OPTIONS <warnings-as-errors>on : -Werror ;
> I can also see the command line generated in bjam form, such as:
> actions compile.c++.without-pth {
> "$(CONFIG_COMMAND)" -c -x c++ $(OPTIONS) $(USER_OPTIONS) -D$(DEFINES) -I"$(INCLUDES)" -o "$(<)" "$(>)"
> }
> and when I compile a particular source. For instance in the output with -d2 I might see:
> clang-linux.compile.c++.without-pth
> C:\Programming\VersionControl\modular-boost\build\boost\bin.v2\libs\lambda\test\algorithm_test.test\clang-linux-3.8\debug\algorithm_test.obj
> "C:/Programming/VersionControl/bninja_installed_clang/bin/clang++" -c -x c++ -D__MINGW_FORCE_SYS_INTRINS
> -Wno-unused-local-typedef -Wno-dll-attribute-on-redeclaration -O0 -g -fno-inline -Wall -g -march=i686 -m32
> -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -o
> "C:\Programming\VersionControl\modular-boost\build\boost\bin.v2\libs\lambda\test\algorithm_test.test\clang-linux-3.8\debug\algorithm_test.obj"
> "algorithm_test.cpp"
> So I know that the action compile.c++.without-pth is being used. But I don't understand how the $(OPTIONS)
> $(USER_OPTIONS) are generated. Is there a -dn b2 switch which will show me how this happens ?

There's no such a switch. The process is roughly this:

- You have a metatarget called "algorithm_test"
- It is generated with a particular set of properties, combining properties on the command like,
   project requirements, and default properties. That produces a set of targets and actions.
- Actions are typically associated with 'action' block, such as what you quote above, effectively
   a command-line template
- Prior to generating final command line, we call toolset.set-target-variables. Given the set of properties,
   and flags previously passed to toolset.flags previous, that function modifies variables specific to
   that that, which are then substituted.

> What I am particularly trying to track down is what generates the -Wall on the command line for clang ? Because -Wall
> gets generated, presumably from a <warnings>on somewhere, all other -W options are ignored ( overridden ). Is
> <warnings>on automatically generated by Boost Build for every toolset somewhere ? I don't think this is the case. But I
> don't understand how this is set nor can I find in the clang.jam, or the gcc.jam from which clang.jam inherits much of
> its functionality, any particular line which is somehow setting <warnings>on automatically. Nor is it being set in the
> library which I am compiling or in my user-config.jam.

So, if you see -Wall, it means that the action has <warnings>on in its property set. That feature is defined
in builtin.jam as follows:

feature.feature warnings :
on # Enable default/"reasonable" warning level for the tool.
all # Enable all possible warnings issued by the tool.
off # Disable all warnings issued by the tool.
: incidental propagated ;

The first value becomes the default, so warnings=off is in property set of every action unless otherwise
specified. For example, you can add <warnings>off on your test metatarget.

- Volodya

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at