From: Robert Ramey (ramey_at_[hidden])
Date: 2006-11-12 12:47:04
David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>> These last failures are one of the following:
>>
>> the Jamfiles depend on the toolset name to avoid running
>> tests which will fail on systems without support for wide
>> character i/o.
>
> That's certainly fixable within the library.
Hmm - I was never able to do it reliably for v1 maybe with V2
this can be made to work.
>> hp acc - has recently started to pass when a user sent
>> me a patch to the test header.
>
> What do you mean by "the test header?"
The serialization tests in include a local common header for
dealing with things like creating temporary files which vary
among environments.
>
>> The current failures suggest something amiss with the testing
>> environment.
>
> Did you report that to the tester?
No. I thought it was obvious from looking at the results. And
apparently it has been as these types of problems seem to
disappear as mysteriously as they appear.
>> a couple of demos - fast_archive, portable archive don't pass
>> when auto-linking is used. They conflict with auto-link in a
>> fundamental way
>
> How so?
I forget the details. I did spend some time on it and that was my
conclusion. Its related to the fact that creating a DLL which exports
a new interface - like portable_binary simultaneously imports
one from the library like binary.
>> so can't really be fixed.
> I doubt that;
at least by me.
> you could explicitly disasble auto-link for those tests.
I was of the idea
that runing auto-linking would create one set of libraries
with the "auto-linking" type names while not using auto-linking
would create more generic names. So I thought that all the
test suite had to be run the same way. Also, even assuimg
it was a good idea, it wasn't clear to me how to do that.
Now that we're moving to v2, I'll take another look.
>> A few borland 5.82 tests fail because they depend
>> upon features in other libraries (mpl, variant) that fail with ths
>> compiler.
>>
>> I guess these last should be noted in expected failures - I was
>> hoping to see the failures disappear as thier root causes were
>> addressed.
>
> Not every library can support every feature on a broken compiler.
> It's up to you to deal with that in your own library, by either
> working around the problem yourself, or by explicitly declaring the
> functionality that depends on the other library to be broken with that
> compiler (i.e. marking the failure expected).
Well, these failures appeared - but now they've gone - Along with one
that had been hanging round for 10 months. I really can't be constantly
marking/unmarking stuff. I think it would be best to wait until everyone
has done what he can then do the marking.
Robert Ramey