"Robert Ramey" <ramey@rrsd.com> writes:
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.
Sorry, I assumed that you meant the problem was that the toolset names have changed; it would be easy to adjust the Jamfiles for that. Actually, it should be easy to use v2's "target alternatives" feature to exclude certain tests from the suite depending on toolset.
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.
That sounds familiar. Don't you write these things down?
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.
I don't think so.
So I thought that all the test suite had to be run the same way.
Nope
Also, even assuimg it was a good idea, it wasn't clear to me how to do that.
just use BOOST_ALL_NO_LIB, unless I'm misunderstanding what you're trying to do.
Now that we're moving to v2, I'll take another look.
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.
Absolutely. -- Dave Abrahams Boost Consulting www.boost-consulting.com