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-10-16 02:18:48

Edward,

I can take a look, but could you send the patch and the command line that
trigger the above error, so that I can be sure I am solving the right
problem?

- Volodya

On Fri, Oct 16, 2015, 08:43 Edward Diener <eldiener_at_[hidden]> wrote:

> On 9/29/2015 10:33 PM, Rene Rivera wrote:
> >
> >
> > On Tue, Sep 29, 2015 at 9:19 PM, Edward Diener <eldiener_at_[hidden]
> > <mailto: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 ;
>
> Unfortunately this sometimes works, but not as a general solution. There
> are some libraries for which the above setup works fine, ie 'bind' or
> 'preprocessor'. But if I try it for testing another library, ie.
> 'function', I get instead:
>
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\feature.jam:782:
> in expand-composites from module feature
> > error: explicitly-specified values of non-free feature <warnings>
> conflict
> > error: existing values: off on
> > error: value from expanding  <warnings>on : on
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\feature.jam:867:
> in feature.expand from module feature
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1070:
> in evaluate-requirements from module targets
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1112:
> in common-properties2 from module targets
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:977:
> in targets.common-properties from module targets
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1303:
> in class_at_basic-target.generate from module object(typed-target)@755
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:774:
> in generate-really from module object(main-target)@3915
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:746:
> in class_at_main-target.generate from module object(main-target)@3915
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:895:
> in targets.generate-from-reference from module targets
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1266:
> in generate-dependencies from module object(typed-target)@2036
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1323:
> in class_at_basic-target.generate from module object(typed-target)@2036
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:774:
> in generate-really from module object(main-target)@3898
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:746:
> in class_at_main-target.generate from module object(main-target)@3898
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:895:
> in targets.generate-from-reference from module targets
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1266:
> in generate-dependencies from module object(typed-target)@1981
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1320:
> in class_at_basic-target.generate from module object(typed-target)@1981
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:774:
> in generate-really from module object(main-target)@3359
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:746:
> in class_at_main-target.generate from module object(main-target)@3359
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:895:
> in targets.generate-from-reference from module targets
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1266:
> in generate-dependencies from module object(typed-target)@2150
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1323:
> in class_at_basic-target.generate from module object(typed-target)@2150
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:774:
> in generate-really from module object(main-target)@2239
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:746:
> in class_at_main-target.generate from module object(main-target)@2239
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:895:
> in targets.generate-from-reference from module targets
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1266:
> in generate-dependencies from module object(alias-target-class)@2232
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:1323:
> in class_at_basic-target.generate from module object(alias-target-class)@2232
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:774:
> in generate-really from module object(main-target)@2260
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:746:
> in class_at_main-target.generate from module object(main-target)@2260
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src/build\targets.jam:272:
> in class_at_project-target.generate from module object(project-target)@2136
> >
> E:/Programming/VersionControl/modular-boost/tools/build/src\build-system.jam:707:
> in load from module build-system
> >
> E:\Programming\VersionControl\modular-boost\tools\build\src/kernel\modules.jam:295:
> in import from module modules
> >
> E:\Programming\VersionControl\modular-boost\tools\build\src/kernel/bootstrap.jam:139:
> in boost-build from module
> > E:\Programming\VersionControl\modular-boost\boost-build.jam:17: in
> module scope from module
>
> Another of those vagaries of Boost Build which makes working with it so
> difficult. Evidently if I have <warnings>off in some place and
> <warnings>on in another place, there is a problem, although the
> occasions which trigger this problem are no doubt more of the Boost
> Build voodoo. For instance in the preprocessor test project requirements
> I specify '<warnings>on' but I do not get the errors above running the
> preprocessor tests. But with 'function' tests it does occur.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
> --
Vladimir Prus
http://vladimirprus.com