David Abrahams writes:
"Robert Ramey" <ramey@rrsd.com> 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