From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-05-02 16:53:02
Sohail Somani wrote:
> 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.
I'm convinced that library authors already make an effort to clear
warnings on the platforms they have available. The real problem is
dealing with platforms not available to developers. For those you do
need to rely on regression reports and feedback after a tentative patch
can take as long as a whole week. Furthermore I'm sure that library
authors already devote to Boost all the time they can afford.
> 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
One improvement would be to move to a bug tracking tool more manageable
than sourceforge's. As a new Trac is being setup, maybe the plan is to
move to its own tool, but I don't know for sure and I'm not familiar
> 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.
For how many platforms at the same time? I don't see this working unless
you're able to ensure nightly regression testing turnaround for all the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk