Re: [Boost-build] From where do compiler options come ?

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

The priority order is roughly this:
- default values, here  warnings=on
- properties on the command line, none in your case
- requirements on projects and metatargets

I am surprised you still get -Wall, I'll take look tomorrow.

On Mon, Sep 28, 2015, 23:19 Edward Diener <eldiener_at_[hidden]> wrote:

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