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:
>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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk