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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-02-01 03:50:48

>> 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.

Wow! This is quite a requirement. This never was true. Though Minimal 
Testing facility has wide coverage.

IMO If we don't run regression tests for the particular compiler no reason 
to expect that anything is working for this configuration. How should I know 
that MSVC6.5 or gcc 2.95 are "still supported". I do not have them anymore.

> 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.

So if some company ABC publish new compiler I need to run and make 
Boost.Test run of it? In reality things not that bad. If you want to try the 
compiler that is not covered by regression tests you could always do so 
(lets assume that ..tools.jam miraculously appeared if not present). Now if 
it fails somewhere within Boost.Test one could come on development list and 
query the status of this compiler. There are two possible responses: 1. Yes 
it's know but unsupported compiler. 2. Oh! New compiler lets try it out. If 
it conformant enough Boost.Test support will appear soon enough.

>>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.

Why? Just because it makes you portfolio bigger? It does indeed not that 
difficult to support old compilers, if ... you are not making any changes. 
Also you should admit that need for old compilers support seriously affected 
you design. Now would you stop trying to hold on to the past you could 
enhance your design, make it clearer and simpler. Eventually need for old 
compilers support will make your own design outdated.

>  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.

It's not for now. It's becoming more and more burdensome while I am trying 
to move away from some "outdated" parts of existent design. But once again 
this is secondary issue here.

>>> 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.

So How come Sunpro 4.2 or gcc 2.91 are less "C++ compilers" than MSVC 6.5? I 
personally still use both at work.

>> 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 covered this in part above. I do not know how difficult this process look 
from you  standpoint.

> I would like to see boost test provide a
> minimal level sufficient to work with boost regression testing.

So now boost internal testing is limited so some very restricted minimal 
subset, because otherwise there is no promise Boost.Test is able to work?

>>> 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 );
[...]
> 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

Why is it odd? Requests for random test case order was quite popular. And I 
do not see anything "corner case" like in faulty code.

Gennadiy