Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at