Re: [boost] Re: [Boost.Test] New testing procedure?

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-05-23 21:42:39

David Abrahams writes:
> "Robert Ramey" <ramey_at_[hidden]> writes:
> > My concern was raised base on the following scenario:
> >
> > a) I get things working to taste on the 3 or 4 compilers I have installed.
> > b) I check in to CVS
> > c) Test is run - takes a long time 
> > d) But shows some problems in the 5 compilers I don't have
> > e) Now I start to fix stuff - more or less one compiler at a time
> > f) Now much computer resource are used to no good purpose.  I can't stop the
> > test from running on the compilers that I know will fail anyway.
> > g) Now my interest shifts to another compiler and a whole different set of
> > wasted effort is done.
> > ....
> 
> OK, but none of the features suggested so far are going to fix that.
> You just want to say "this library/test doesn't work on these
> compilers", and as you start to implement workarounds for each
> compiler, knock it off the list so it'll be tested.  We currently
> already have a way of expressing that "known to not work on X
> compiler" idea in the regression system.  We could make the build
> system smart about it.  
> 
> Probably simpler, though, you could just put something in one of your
> library headers that said:
> 
> #if BOOST_WORKAROUND(compiler1) || BOOST_WORKAROUND(compiler2) || ...
> # error doesn't work yet
> #endif
> 
> And the tests would take very little time when they are known to fail.
> Hmm, that would cause retesting of known-working configurations.  I
> guess a change to the build system would be superior.

It would be. What needs to be done to implement it?

--
Aleksey Gurtovoy
MetaCommunications Engineering