|
Boost : |
From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-05-02 12:00:34
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Vladimir Prus
> Sent: Wednesday, May 02, 2007 8:07 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [1.34.0beta] many, many warnings... :(
>
> Marc Mutz wrote:
>
> > I for one think that this is
> > a serious issue, and I encourage you to accept such patches (not for
> > 1.34.0, obviously, but 1.34.1) and make it a release goal
> for 1.35 (or
> > 1.34.1) to reduce the number of warnings to a decent level.
> Maybe change
> > the regression tests to highlight any kind of compiler
> diagnostics in
> > <pick your favorite color>.
>
> The problem is that the current regression reporting tools don't count
> warnings (previous version use to), so there's nothing
> nagging developers
> about warnings introduced in their code.
If you treat warnings as errors and if bjam has an option to "keep
going" as much as possible, then you get builds as far as they can go
(i.e. all the warnings) and builds fail if there are warnings. Then I
think you don't need to depend on the regression reporting tools for the
rest of time, atleast for this stuff.
Usually the warnings I've seen in Boost are pretty easy to fix but its
understandable that that puts yet another load on the developers. The
"problem" with patches is that they take forever to get accepted and/or
commented on as they are lots of little loads and resources are limited.
Warning-fixing patches are understandably lower priority than
segfault-fixing ones. Maybe a catch-all-warning-fixes bug is in order if
we can get some sort of resource with commit privilege to look over it?
The prerequisite is that the patches should ONLY quiet warnings.
If we do this, and then at some point accept this catch-all set of
patches, then we can turn on warnings as errors once the patches have
been merged. I've had to do this before, and this works as far as
setting you up for the future.
Sohail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk