Re: [boost] [1.34.0] Boost.Build

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-11-12 12:37:46

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>> 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?"

serialization/test/test_tools.hpp

>> The current failures suggest something amiss with the testing
>> environment.
>
> Did you report that to the tester?
>

The tester saw it :-)

As I said in my previous reply, it was some intermittent I/O problem:
the compiler could not open STL include files. It disappeared as
mysteriously as it appeared: for the past two tests run, serialization
library is all green.

Boris, the "tester"

----- Original Message ----- 
From: "David Abrahams" <dave_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, November 12, 2006 11:58 AM
Subject: Re: [boost] [1.34.0] Boost.Build

> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>> Thomas Witt wrote:
>>
>>> FWIW the decision to use v2 was made a long time ago.
>>
>> The decision was made AFTER the branch for release.
>
> No, it was made LONG before the branch.
>
>> When this branch was made it was explicitly stated that
>> only bug fixes should be commited to the release branch.
>
> We were talking about C++ code.
>
>> This admonition was ignored when the decision to commit
>> to v2 was made, which was not a bug fix but a feature
>> enhancement. I'm sure this opened the door to more
>> subtle feature enancements whch has resulted in a release
>> branch lifetime of 10 months rather than say one month.
>
> The switch to v2 may have slowed us down by a couple of weeks at most.
>
>>>
>>> Thomas
>>>
>>> PS: What's the status with respect to outstanding serialization
>>> regressions. Is there anything I can do to help get these fixed?
>>
>> I've concluded that all ounstanding serializaton regressions are
>> not addressable with changes from within the serialization library.
>> So anything not passing now shuold be marked as "expected failure"
>
> So mark them.
>
>> 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.
>
>> CW 8.3 passes/fails and switches back and forth without
>> any changes on my part.
>>
>> 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 current failures suggest something amiss with the testing
>> environment.
>
> Did you report that to the tester?
>
>> 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?
>
>> so can't really be fixed.
>
> I doubt that; you could explicitly disasble auto-link for those tests.
>
>> I'll add
>>
>> 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).
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>