Boost logo

Boost-Build :

Subject: Re: [Boost-build] Boost.Build causing failures on the release branch (and Trunk too)
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-11-19 23:41:56

Sorry, still too busy to give much feedback on this stuff. I literally
got home a few minutes ago and I already need to back to sleep :-(

Vladimir Prus wrote:
> John Maddock wrote:
>> There seem to be a lot of failures on the release branch caused by some
>> libraries not being found, so for example on acc:
>> or on Darwin:
>> The library not being found is part of the project requirements BTW in case
>> that helps,
> On the *release* branch? I am confused what is going on -- the only explanation
> would be that trunk Boost.Build is being used to test release state of C++ Boost.
> Ah, right, I recall we discussed this being the case. So, to summarize,
> the current testing arrangement appears to be:
> 1. For release branch:
> - C++ Boost -- release branch
> - Boost.Jam -- stable release
> - Boost.Build -- bleeding edge
> 2. For trunk:
> - C++ Boost -- bleeding edge
> - Boost.Jam -- stable release
> - Boost.Build -- bleeding edge

Yep. And when I brought up the release testing last year, I mentioned
that the ideal for C++ Boost would be:

   - C++ Boost -- release branch or bleeding edge
   - Boost.Jam -- stable release
   - Boost.Build -- stable release

But there wasn't a stable Boost.Build at the time, and it didn't look
like there would be one for some time. Especially as it would mean
changing the BB release process a little bit to have formal releases.
The rationale is that C++ Boost is a *user* of bjam and BB, and hence
should only ever be using/testing with release tools. And that the tools
should be tested separately, and exhaustively. Hence I want a tools
testing process so that we can hammer on the tools repeatedly and
quickly without worrying about the possibility of breaking C++ Boost
testing. I know it seems strange for me to say this, but the BB failures
are an example of the kind of failures we used to see many times for C++
Boost testing which was a horrible pain as it would stall C++ Boost
testing. And that is the key problem we must avoid. The current
compromise is not ideal, but it's just slightly less problematic than it
used to be.

> Seem fairly strange to me.

It's only strange because it's a compromise.

> For one thing, as I've complained already on
> boost-testing, we never test Boost.Jam trunk + Boost.Build trunk, so
> we'll never detect any breakage in that combination. And at the same
> time, we use in-development version of Boost.Build for release testing.
> I would say we should use release branch version of everything for
> release branch, and trunk version of everything for trunk.

The testing I want to see is:

   - All C++ Boost use release quality tools.
   - All tools tested to the same level as C++ Boost. Which would also
include testing C++ Boost, release and trunk, with development level tools.

But this, of course, means more testing resources.

PS. And yes, I'll finally be getting around to putting together the next
bjam release this weekend assuming I don't end up working overtime. As I
finally have my Linux machine/partition running again.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ (msn) - grafik/
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at