Boost logo

Boost :

From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-05-02 13:59:56

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] 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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at