Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-09-30 13:05:23

Aleksey Gurtovoy wrote:


>Pending msvc-stlport issue aside,

I commented this accordingly.

>the serialization library reports show
>quite a few failures with other toolsets, in particular:

> cw-9.3
> borland-5.6.4
> cw-8.3
> msvc
> vc7

>I'm sure you've well aware of these; what I'd like to ask you is to
>comment on them in the "explicit-failures-markup.xml" in the similar
>way you commented on "*_warchive" tests, so that a) the library users
>are not scared away by all these yellow cells, and b) the release
>manager and everybody else besides the author have a simple way of
>telling whether the library is in the OK state or not.

I've been looking at this for a while procrastinated doing anything until I
was sure what to do. So far this has been an effective strategy. Many
times failures just disappeared as arcane tooI set issues were resolved. I
still have some doubts about how to handle the remaining cases.

Metrowerks compilers (cw*) seem to suffer from over-zealous optimization
that eliminates static variables not referred to explicitly by name. Other
compilers do this as well, but I've managed to workaround this in various
ways. Cw* is the last hold out on this issue. I had hoped someone who is
interested in this can test it might be motivated to look into it but it
seems that there isn't enough interest. Unless I hear otherwise, I'll mark
these tests as "expected". I would love to see this fixed - but for this
Metrowerks would have an almost perfect showing. I do think its very high
quality product that handles platforms that others don't. Its pains me that
the serialization library test don't reflect this.

A number of these (msvc, vc7, borland) have been determined to be
manifestations of compiler deficiencies so I will mark them so.

Some the borland test don't fail on my own test setup - so for me they are
indeed "unexpected failures" - I think leaving this yellow is the correct

That leaves a number of miscellaneous failures which really aren't
understood or explained. Personally I would like to leave these as they are
as to mey they really are "unexpected failures". I realize that some might
be dissuaded from using the library because of this - but I think that's
better than having someone use the library and not have it meet

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at