Re: [boost] [Release 1.34] Supported Compilers - another view

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-01-31 15:29:14

> It really points to the design of boost test itself. I understand the
> the problem - library development gets driven be feature comparisons
> with other libraries, wish lists, "cool" features, and I think more
> mundane aspects like a good "user directed" manual

Group of volunteers and me at the moment working on Boost.Test documentation 
update. If you have any particular requests and/or willing to participate - 
please let us hear it.

> conceptual
> transparency, idiot-proofness etc seem to lose importance.

You need to be more clear for me to understand what exactly you are 
"missing"

> Actually, maybe my concerns can be addressed by going back
> into boost test and using the "minimal" option.  If its not possible
> now it should be easy for boost test to be jiggered around
> so that functionality is of several levels - for example
>
> a) minimal - see below
>
> b) standard - sufficient facilities for simple regression testing - works
> on all conceivable compilers - LOL
>
> c) better - more features - compiler support at discretion of
> the boost test library author.  Would require a table of which
> features are supported by which compilers.  This would be free
> as the table is already generated by the boost regression testing.
>
> d) delux - every bell and whistle ever suggested that the library
> author wants to implement.

Essentially the state of affairs is like this already. There is the Minimal 
Testing Facility component (header only). There is the Unit Test Framework 
that works on most compilers. And there are new features that ifdefed out 
for old compilers. But my position is that we need to consciously move away 
from old compilers to make code base healthier. Requirement for feature 
compiler support is also scaring. I would really prefer not to do this.

> As I said before, I think that Boost Test could be much, much
> more important than it is in drawing new users to boost. For
> this to happen I would like to see:
> a) an easier to read and use manual
> b) a minimal level implemented as header only so that users
> in need of immediate gratification could get it.  This would
> address the user who turns to boost because he's under
> huge pressure to find a bug.   Solving someone's problem
> in less than two hours is going to turn anyone into a boost
> booster.

This looks like two contradictory goals: you may not be able to solve 
someone problem in 2 hour using facility with minimal functionality

Gennadiy