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

Subject: Re: [Boost-build] From where do compiler options come ?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-09-29 22:33:14

On Tue, Sep 29, 2015 at 9:19 PM, Edward Diener <eldiener_at_[hidden]>
wrote:

> On 9/29/2015 3:05 AM, Vladimir Prus wrote:
>
>> On 29-Sep-15 9:57 AM, Vladimir Prus wrote:
>>
>>> On 28-Sep-15 11:25 PM, Vladimir Prus wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Edward,
>>>
>>> with the patch below, when I run "b2 --debug-building", I see that
>>> <warnigns>off is in build properties. With msvc, I also see /W0, which
>>> is the expected warning option. Could you try exactly same patch and see
>>> whether -Wall is still there?
>>>
>>> --- test/Jamfile
>>> +++ test/Jamfile
>>> @@ -15,7 +15,7 @@ project
>>>     ;
>>>
>>>   test-suite lambda
>>> -  : [ run algorithm_test.cpp ]
>>> +  : [ run algorithm_test.cpp : : : <warnings>off ]
>>>       [ run bind_tests_simple.cpp ]
>>>       [ run bind_tests_advanced.cpp ]
>>>       [ run bind_tests_simple_f_refs.cpp ]
>>>
>>
>> The same patch also eliminates -Wall on Ubuntu with gcc.
>>
>
> What I see is that I can override the -Wall default if I specify
> "warnings=off" on the command line. Also if either the jam file has project
> requirements with "<warnings>off" or individual target has the
> "<warnings>off" the -Wall default is overridden.
>
> However evidently, as specified in the documentation for the gcc toolset
> at
> http://www.boost.org/build/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.gcc,
> the end-user can not use "<warnings>off" ( or any "<warnings>" option ) at
> the toolset level. I am trying to use it for clang, not gcc, but there is
> no documentation for the clang toolset in the Boost Build docs so I assume
> the same restriction goes for clang. Is there a reason why general
> requirements could not be part of the 'using' rule aside from the fact that
> it was not designed that way ? It would surely be useful to specify any
> feature, and not just the limited features which are direct compiler
> options, in the 'using' rule. I think the end-user should be able to
> specify a general requirement for his toolset which overrides the default
> requirement. My particular need is that clang outputs an awful lot of
> detail even when warnings occur, so I would like to limit as an end-user
> the warnings for that compiler. Doing it on the command line is possible
> but it is much easier if I could do it at the toolset level and treat the
> command line generically as to the toolset ( which is what I currently do
> by invoking 'b2' from batch files ).

I think what you are after is toolset requirements <
https://github.com/boostorg/build/blob/develop/src/build/toolset.jam#L574>.
Which you could use by adding in your user-config.jam something like:

===
import toolset ;

using clang ;

toolset.add-requirements <toolset>clang-linux:<warnings>off ;
===

HTH.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail