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' ?

> For example, you can add <warnings>off on your test metatarget.

I add <warnings>off for my toolset definition, but it does not remove
-Wall from the command line. I suspect that properties specified in the
toolset definition are ignored and only actual flags via cxxflags,
cflags, or linkflags are valid and processed.

The issue as I can understand it is that if there are conflicting
<warnings> settings coming from different places how does that get
resolved ? Sorry to be redundant but that seems the essence of what I am
trying to understand. I can understand that <warnings>on is the default
but surely I should be able to override that default so that -Wall is
not output on the command line at all.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build