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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-02-01 00:58:54

Gennadiy Rozental wrote:
>> 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.

> This is not exactly true. IMO. Boost.Test need to support only those
> compilers we are running regression tests on.

That's were we disagree.  Boost Test is so fundamentally important that
I  think it should support some level of functionality for any C++ compiler.

Actually I can't really determine the boost compatibility for a given
C++ compiler until I run some of the tests - at least config.  But if I 
can't
run boost test - well.  Who knows, its conceivable that some C++ compiler
has decent compliance but just happens to trip on a specific issue that
Boost Test - delux version - trips up on. So we entirely mis-catagorize
this particular C++ compiler as a basket case- when in fact it
might be just slightly wounded.

>If library author or
> any other interested party want to employ old compiler they will have
> to use older version of Boost.Test.

yep - and that's my complaint.  The serialization library still supports
msvc 6 and compilers which don't support partial specialialization and
compilers which don't support partial function template ordering.  It also
works with Borland 5.51 and 5.64.  If I were writing the library today
I probably wouldn't have invested the effort required to do this.  But
now its done and in my view its a pity to throw it away.  It costs me
very little to maintain compatibility at this point.  So I would like to
continue this as long as its not too inconvenient to do so.  All I need
to do this is for boost test to keep working at the level I've been
using it.  I don't think that's toooooooo unreasonable.

>> So Boost Test should be structured so that it doesn't
>> break old tests.
>
> Lets say library author want to  support Sunpro 4.2. Does it mean 
> Boost.Test have to comply. The fact that MSVC *was*
> used for regression testing sometime before shouldn't make any
> difference IMO.

LOL - well I can't force you to make boost test support these compilers.
But I've come to depend on boost test for ALL my testing.  So if you
can't do ths- then I'm sort of stuck.

> Actually I believed it was kind of agreed upon: 1.34 doesn't support
> MSVC anymore. Is there any particular reason you want to hold on to
> this compiler?

Now here is the rub.  I started this thread with the proposition that its
not practical to fix a boost wide policy as to which compilers will
be supported and which will not be.  The best decision will depend
on the pecularities of the library in question and its application.
Ultimately it will depend upon the library author in any case.  You
can' t even fix a policy for regression tests.  Suppose a new test jumps
in with a new platform - QNX with DMC compiler - who is going to
tell him he can't test this because its not our policy.  So its going to
happen.  The only question is are we going to make as easy as we
can for him or not?.   I would like to see boost test provide a
minimal level sufficient to work with boost regression testing.
Actually I'm pretty sure its mostly all in there - its just not obvious with
a cursory reading.

>> 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.
>
> You meant build of unit test, right?

I link with the exectution_monitor library

>> Commenting this
>> out permits the serialization libary to be tested with comeau.

> There should be another way. I do not have an access to this
> compiler. Maybe you could rewrite with statement somehow?

I don't remember how I discovered this but once I tweaked my local copy
and I could run the commeau tests I moved on.  The commeau tetsts weren't
in the regression table.  I just ran them on my own machine because I like
the way that compiler works over my code.  I'm not sure what the "real"
fix is and maybe its not worth fixing for this "corner case".  It was odd to
me that this code got included in the library but as i said I didn't really
investigate it.  This occured after 1.32 and before 1.33.

Robert Ramey