From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-03-06 13:08:26
My personal opinion is that there should be no <warnings>default. Instead,
if my jamfiles don't specify <warnings>, BBv2 should not pass any
warnings-related compiler options on the command line. This will use the
default setting of the compiler. If someone wants to introduce project-wide
defaults that are different from the compiler's defaults, they can do it in
Secondly, if I use <warnings>all, I want all warnings. Whether this makes
the compiler output too verbose is not up to us, it's up to the user. My
personal preference when using the MSVC compiler is to use <warnings>all,
and then disable a few individual warnings.
Which is why being able to disable individual warnings is very important,
and that is currently broken for the GCC toolset.
On that note, I would appreciate if BBv2 had easier support for customizing
the command line for specific files. Yes, I can define obj target, but then
I can't simply glob for my files, since I get duplicate files. It would be
nice if I could glob as usual, and then somehow list the files that need
custom options, together with the custom options, all in one place.
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: "Boost.Build developer's and user's list" <boost-build_at_[hidden]>
Sent: Monday, March 06, 2006 12:14 AM
Subject: Re: [Boost-build] warnings (was: Problem with disabling warnings
> On Friday 03 March 2006 15:57, Reece Dunn wrote:
>> What if we have a <warnings>default option or equivalent that translated
>> to: <toolset>gcc/<warnings>default ==> <warnings>all
>> <toolset>msvc/<warnings>default ==> <warnings>on
>> <toolset>cw/<warnings>default ==> <warnings>on
>> This would retain the meaning of off, on and all so the user can specify
>> these and provides a means of getting a reasonable level of warnings for
>> compilers where <warnings>all is a bit too much. <warnings>default could
>> then be tailored to each compiler so some of the more verbose warnings
>> could be disabled (e.g. msvc's unreferenced argument) without impacting
>> meaning of on or off.
> This is technically possibly, but that would mean that <warnings>all will
> still unsuable with msvc, because it will produce a large number of
>> However, I am open to suggestions.
> I think we should <warnings>all add /W3 on msvc, and simulary lower the
> warning level for CW.
> - Volodya
> Unsubscribe & other changes:
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk