From: David Abrahams (dave_at_[hidden])
Date: 2006-11-12 13:42:47
"Robert Ramey" <ramey_at_[hidden]> writes:
> 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.
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
>>> 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.
> 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
>> 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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk