-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: Wednesday, May 02, 2007 8:07 AM To: boost@lists.boost.org 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