# Boost-Build :

Subject: Re: [Boost-build] From where do compiler options come ?
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-09-28 16:19:05

On 9/28/2015 3:40 PM, Vladimir Prus wrote:
>
> Edward,
>
> 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,

I assume you mistyped and mean "command line". That I understand.

> project requirements, and default properties. That produces a set of
> targets and actions.

Are properties specified in toolset definitions ignored or invalid ?

Understood. Then is it possible to have "conflicting" values for a
particular property, for instance <warnings>off from one place ( ie. the
command line ) and <warnings>on from another place ( ie. the project
requirements ) ? How is that resolved ? Surely not each value for the
particular property is added to the command line as a separate
command-line parameter ?

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

I see this in build\src\build\toolset.jam. Are individual toolsets
allowed to override this processing ? If so I don't see it anywhere else
for a given individual toolset.

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

Why is 'off' the first value. Isn't the first value 'on' ?