David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> 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