Re: [boost] [1.34.0] serialization, spirit, borland and msvc-6.5

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-01-28 16:53:29

Rene Rivera wrote:
> Robert Ramey wrote:
>> Actually this kind of approach has interested me for some time.
>
> [cut]
>
> That's not what I meant... What I meant is that *you* can change the
> serialization *code* to disable the serialization library features
> when they are not available/usable.

But they would still show up as failures in the test system.  The test 
results
would look the same.  That's why I am attracted to idea of running only
those tests which actually test something expected to work.  This requires
some sort of feedback from config.h to the test system which is
why I was thinking of a small test program which would fail if
the system can't be built and make the other tests dependent on that test.

>> Note that these tests
>> pass with V1 so the issue isn't with the serialization library
>> itself, its just that that is where some "corner cases" show up.
>
> BBv1 had kludges to suppress/work-around the errors in the
> serialization library.

I am not aware of any such errors in the serialization libary. I don't 
consider
it an error that some compilers cannot support conforming code - and I don't
think boost does either.

I'm not aware that BBv1 had/has any such kludges.  V1 jamfiles had
some "kludges" to permit testing on these platforms.  These reflect weakness
in V1 which I'm hoping have been addressed in V2.  For me the jury
is still out on this as I haven't really re-visited Jamfiles with V2.

> Depending on the build system for portable software is never the best 
> solution.

I'm depending on the build system for building and testing the library to 
the extent that it is supported by the compiler and environment.  I believe 
that is what the build/test system is for.

In the case in question, the serialization library depends upon spirit to 
parse xml input. The boost version of spirit - 1.8 does not support these 
compilers.  So the serialization
library doesn't either.  The developer's of spirit have kept 1.6 around for 
such situations
the users of the serialization libary with these compilers have the option 
to use spirit 1.6 or not use xml archives.  These are all legitimate 
options. Ideally the build/test system would support the options preferred 
by the user.

Note that the whole issue is repeated with regard to wide char i/o.  It 
doesn't really show up now that it seems that (almost?) all platforms being 
tested support wide char i/o.

So to me, there are couple of disjoint issues.

a) getting 1.34 out in the "best" way.
b) how should libraries which support different levels of functionality be 
handled with V2?  I really think this should be handled in the HEAD branch.

Robert Ramey