Re: [Boost-build] Boost.Build causing failures on the release branch (and Trunk too)

Subject: Re: [Boost-build] Boost.Build causing failures on the release branch (and Trunk too)
From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-11-22 03:47:15

On Thursday 20 November 2008 07:41:56 Rene Rivera wrote:
> 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 :-(

I hope we're close to a solution :-)

> 
> 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:
> >>
> >> http://tinyurl.com/6r76o5
> >>
> >> or on Darwin:
> >>
> >> http://tinyurl.com/6dyezn
> >>
> >> 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.

Don't let ideal solution get in the way of a better solution -- surely,
using release branch version of Boost.Build for testing release branch
of C++ Boost is better than using trunk Boost.Build? 

> > 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.

Given that Boost.Build testing is fairly light on resources, I think the
only way forward for me now is to make regression.py build a second copy
of boost.jam, from trunk sources, and use that when doing Boost.Build
tests. This way, we'll be able to verify that at least Boost.Jam+Boost.Build
trunk pass their own testsuite. Any objections?

Ideally, we should also be doing C++ Boost testing with Boost.Jam+Boost.Build
trunk, at least in some configurations, but this will indeed increase the
required resources, and might be less important once Boost.Build testing
is automated.

> 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.

Great.

- Volodya