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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-31 12:43:50

I've come to believe that the huge amount of discussion
regarding how compilers should be classified is another
symptom of the (excessively?) close coupling of
boost libraries.  The first symptom is the disproportionate
amount of effort required to make a new "release" which
has been discussed on another thread.

With a couple of caveats noted below I see no reason why
all libraries have to support the exact same set of compilers
at the same level.  As an example consider a couple of
libaries.

spirite and lambda - these absolutley depend upon high
compiler conformance.  Anyone seriously interested in
using tools like this and the techniques they embody will
not be using msvc 6.0 .  Demand and utility of msvc 6.0
for these libraries approaches nil.

smart_ptr, iostreams and others.  These have wide
applicabilty and probably demand for those using
MSVC.  I'm sure that the developer of smart_ptr
suffered with MSVC 6.0 - but its over now and
I doubt that just keeping it up is  a big problem.
I suspect that msvc 6.0 compatiblity for iostreams
issn't too bad.

All in all I think its fine that each author decide what
level of support to give each compiler.  The current
test system permits a compiler to be marked as
supported/unsupported on a library by library basis.
This is just fine.

Of course library authors and the review process will
have to resolve what level of support is appropriate
for each combination of library and compiler.  I just
don't see how there is anyway to agree blanket
policy "compiler X is supported/deprecated" etc.

So now it comes down to individual libraries.

The only time this comes up as a boost wide
issue is for libraries which are used by other
boost components.

The current case is that of Boost Test.  Lets
consider this library in particular.

Boost Test is used by ALL libraries in boost
to test themselves.  For it to be an effective
in this role, it must be usable with any compiler
that is supported by any library.  This is not
a suggestion or normative statement.  Its just a
recognition of the fact that it can't do the job it
has been doing if it doesn't support older compilers.
So Boost Test should be structured so that it doesn't
break old tests.  It can add new features that are
supported only in new compilers but it should
be able to continue to provide the support it has
in the past.  I realise that this is an extra burden
that other libraries don't have to shoulder and
maybe its not "fair" but it is part of the requirement
for Boost Test to continue in its fundamental
role in boost.

A couple of random observations re boost test.

It has been a fundamental contributer to a big
change in the way I do my programming.  It deserves
full credit for that.  I'd read the "continuous testing"
mantra and believed it in theory - but without a
fully implemented test sytsem with good documents
to teach me how to do it and make it easy to do
I wouldn't have been converted.  I suspect that my
experience is common in this regard.  Boost Test
is special it has to be almost universal in order
or full fill its extremely important and special role
in boost and in C++ development in general.  I
appreciate that the author of Boost Test thinks its
a pain in the rear to address the "old compilers" but
he is too modest in appreciation of his own work and
I'm sure that if knew how important it really has been
and he would just say "$%%&%&*" OK and
accept his lot and keep it widely compatible.

I think that boost test is plenty sophisticated
an complete feature wise.  Maybe too much - which
is what might be creating the compatiblity issues.
The main obstacle to "selling and promoting" boost
test is that the documents need work to make boost
test more obvious to a new user - (and to me as well).
The perspective should be to "increase market penetration"
of boost test rather than "increase functionality" of
boost test.  In my view, lack of ease of use is currently
a larger obstacle to "increasing market penetration" than
limited feature set and this is where effort should be
invested.

An and another thing. It damn annoying to find that
all my tests suddenly fail on msvc because of a change
in the test system.  Oh I'm sure it was announced somewhere
and I don't care - its annoying none the less.  Now what
am I to do?  Stop supporting msvc? Shouldn't that be my
decision?  Re write my tests to not use boost test?  I don't
want to do that!

Finally, I managed to get the serialization libraries test
to work with comeau by commenting out some of boost test.

unit_test_parameters.ipp

//    const_string rs_str = retrieve_framework_parameter( RANDOM_SEED, argc, 
argv );
//    s_random_seed       = rs_str.is_empty() ? 0 : lexical_cast<unsigned 
int>( rs_str );

This apparently instantiates some basic_stream template that the 
serialiation library
also instantiates.  The comeau 4.3.3 prelinker complains about this - which
I don't thnk it should - and build of serialization library fails. 
Commenting this
out permits the serialization libary to be tested with comeau.

Robert Ramey