Re: [boost] [1.34.0] Boost.Build

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
> 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