Re: [boost] [1.34.0] Boost.Build

From: David Abrahams (dave_at_[hidden])
Date: 2006-11-12 11:58:22

"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