Re: [boost] [1.34.0] Boost.Build

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