-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Wednesday, May 02, 2007 10:48 AM
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.
It would take a lot to convince me to require that Boost builds with all warnings enabled and treated as errors. There are just too many "nuisance" warnings out there, and since GCC gives us no way to explicitly suppress warnings in code, we'd have to write convoluted (and sometimes even inefficient) code just to silence them.
But most (not all, for sure) warnings can be disabled by -fno-some-feature. The only places where you might have to change the code would be in the cases where the warning cannot be disabled. Anyway, isn't it enough to convince you to think about it that someone has taken a branch locally just to silence warnings? I've done something similar by having a set of patches that I applied to pristine sources. I can't imagine we're the only ones. Having "disable this warning" flags in the build file may make it apply to more files than is really necessary, but I believe bjam does handle per-file application of flags quite nicely. Though I don't use it so I might be wrong. Header-only libraries however... Sohail