Re: [jamboost] Re: [BBv2] warning support

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-19 05:51:14

Vladimir Prus wrote:
>On Saturday 17 September 2005 22:09, Reece Dunn wrote:
> > Thanks for the link! In the description of incidental: "A feature that
> > controls a compiler's warning level is one example of a likely
> > incidental feature." :). Even Volodya agrees with you.
>
>IIRC, that sentence text belongs to Dave ;-) But yes, if you omit 
>"incidental"
>you'll get warning-as-error-true in the target path, which is not what you
>want.

:) Indeed.

> > I have provided an updated diff based on feedback.
>
> > +feature warnings :
> > + on # turn warnings on
>
> Heh, what does that mean? Which warnings are turned on? I'd prefer this
> to be spelled down.

How about: "Enable a tool-defined set of warnings that enables 
'compile-time' warnings according to that tool." :) This will, in most cases 
be a "warnings=on" flag.

> > + off # turn warnings off
>
> All warnings? Again, I'd rather have this spelled down.

Yes: "Turn off all warnings issued by the tool."

> > + all # enable all warnings
>
> > +flags gcc.compile CFLAGS <warnings>on : ;
>
>This can be removed, as it has no effect.

Noted. Although I have seen other declerations like this in other toolsets 
(e.g. como).

> > +flags gcc.compile CFLAGS <warnings>off : -w ;
> > +flags gcc.compile CFLAGS <warnings>all : -Wall ;
>
>I'd argue that <warnings>all should be a default. Noted that gcc.jam now 
>has a
>hardcoded -Wall, so:
>
>1. You proabably need to remove that hardcode, or verify that feature 
>indeed
>overrides -Wall (I think so).
>2. If you remove hardcode, I'd prefer <warnings>all to be default.

I didn't notice that! You are right - it should be removed and <warnings>all 
made default. Note that this will significanly increase the number of 
warnings issued (especially by the msvc compiler)!

In a previous incarnation, I had a 'default' value for warnings that would 
be "the tool's default list of enabled warnings", but it was felt that 
default <==> on. I am happy either way as there are benefits to both 
approaches.

- Reece