Re: [Boost-build] [Boost-cvs] CVS: boost/tools/build/v2/tools gcc.jam, 1.82, 1.83

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-26 01:11:56

On Thursday 26 October 2006 01:06, Eric Niebler wrote:
> Rene Rivera wrote:
> > Eric Niebler wrote:
> >> Rene Rivera wrote:
> >>> Eric Niebler wrote:
> >>>> Jürgen Hunold wrote:
> >>
> >> Not sure what (..) part you're referring to, but if I execute "g++ -v"
> >> from cygwin, this is what I get:
> >
> > It's usually the last part of the output when doing "g++ --version".
> >
> >> gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
> >
> > Which I think in the "-v" it's the "(cygming special)".
>
> $ g++ --version
> g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
>
>
> 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.

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.

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

-  Volodya