Re: Warnings in regression test output [Was: [boost] minor fix for token_functions.hpp]

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-07-20 07:53:36

At 04:09 PM 7/19/2001, Greg Chicares wrote:
 >Thomas Matelich wrote:
 >>
 >> This brings up the issue of warnings.  I realize we don't want to 
reject
 >> code based on warnings, but maybe the regression tests could start
 >> making files to show compiler output for the tests.  I wouldn't put
 >> those in CVS necessarily, but often warnings from one compiler will be
 >> errors on another, so having access to those will make
 >> maintenance/upgrading a little nicer.
 >
 >I think it would be handy to have all[1] warnings in the regression
 >test output. Anyone who reads that is probably interested in all the
 >information they can get. Knowing what other compilers say can help.
 >
 >Making this stuff more readily available than that isn't a good idea,
 >because naive users might see it as a measure of quality and not
 >realize that some warnings don't necessarily reflect on the quality
 >of the library. Even worse would be to give a summary with counts
 >of warnings.
 >
 >[1] What does it mean to enable 'all' warnings? Not all compilers
 >have a monotone none...some...lots...all switch. For instance,
 >gcc can warn about member order mismatches between the initializer
 >list and the class declaration, with the -Weffc++ switch. But
 >that switch, by enforcing OOP practices, complains about STL.
 >There's an art to choosing the warnings that make sense.
 >
 >OTOH, is anything gained by saving, say, msvc warnings in addition
 >to those generated by a picky EDG compiler like comeau?

Dave Abrahams is working right now to set up Boost.Build to run the 
regression tests.  Because of that, it wouldn't make sense to put a lot of 
effort into the current compiler configuration.  But once that change is 
complete, it would make sense to review the compiler warning settings and 
try to come up with an optimal configuration.

I'm sure any help would be welcomed!

--Beman