Boost logo

Boost-Build :

From: Eric Niebler (eric_at_[hidden])
Date: 2006-10-26 13:51:48

Vladimir Prus wrote:
> On Thursday 26 October 2006 01:06, Eric Niebler wrote:
>> Rene Rivera wrote:
>>> Eric Niebler wrote:
>> I'm also not wild for the idea having a specially tagged "known good"
>> BBv2. What's on HEAD should be "known good," and HEAD should be what the
>> nightly regression tests are testing. A more comprehensive BBv2
>> regression test is all that should be needed, IMO. A few people were
>> broken by these changes. Their configurations should be captured in test
>> cases so the bugs don't creep back in.
> The problem is not the regression tests. In fact, my nightly build -- which is
> automated -- crashed right after this change went in, so post-checkin testing
> caught this problem just fine.

Phwew! That's comforting.

> The problem is that Rene does not have access to Ubuntu's gcc compiler, nor to
> cygwin's gcc compiler, so he could not test with those compilers.

That's a problem. No *nix? No Windows? Rene, what do you use, a Mac? If
you're going to be hacking toolsets, we need to get you access to
platforms you can test on.

/me wishes once again for a Boost compile farm.

>> If the BBv2 regression test cannot be made comprehensive enough, I'd
>> rather see an experimental branch for toolset changes that some on this
>> list (myself included) sync to. That branch gets merged into HEAD
>> periodically if none of us guinea pigs have complained.
>> But that's a poor substitute for a good set of BBv2 regression tests.
> We've being though this before on Boost mailing list. IIRC, that was in
> relation either to Boost.Serialization or Boost.Test -- where each change
> either requires a lot of time in recompilation or potentially breaks a lot of
> code. The idea was to have a separate branch, where changes should be
> preliminary tested before disruption HEAD.
> In that case, just like in the present case, the problem is not in the number
> or quality of regression tests. The question is how to test a change that can
> break one of 100 different gcc versions out there without committing it to
> HEAD. Perhaps the right solution is just to ask on mailing list for more
> testing for disruptive patches -- they don't appear too often.

Yes, that sounds about right. But an UNSTABLE branch would make this
scenario easier.

Eric Niebler
Boost Consulting

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