[boost] Re: [Boost.Test] New testing procedure?

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-22 12:39:08

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

>> > In this particular case
>> > It was working on all compilers but Borland.
>>
>> ??! The links I posted were for problems uncovered by Comeau.  Did
>> you look at http://tinyurl.com/35ole?  Several other compilers also
>> detect the issue.
>
> I do not have cameau not inter compilers. Among compilers I have
> access to it failed on command line Borland only.

Oh, I'm sorry.  I didn't realize you were referring only to
compilers you had tested on.

>> > I posted request for workaround while ago. Still no response.
>>
>> I could be wrong, but AFAICT there's a bug in the library.  It
>> shouldn't be up to others to find workarounds for that.
>
> Hardly. I am quite confident library code is correct.

OK, having looked, I am inclined to agree.  At least the standard
strongly implies that derived classes can increase access to base
class protected members by use of a using declaration.

>> > I had to test other configuration and I committed it. Actually I was
>> > surprised that so many compilers had an issue with completely
>> > innocent using declaration. Anyway I think it should be fixed as of
>> > last night.
>>
>> Not according to the links I posted *this morning*.

The dates on the test were from the 21st, but...

> There may be some differences between metacom and mine "last
> night". Check now. 

...Comeau seems to be cured now.

> I do not know what is the version of intel compiler and couldn't
> switch to hack workaround for it.  

I think the simplest answer for compilers that can't handle your using
declaration correctly is just to make the member public.  Misuses will
still show up with other compilers.

> BTW I remember that for
> non-metacom formats it is possible to see the runtime result of
> config test. It is very convenient. Could we make metacom format to
> include it?

I think you'd better post a specific question about that to make sure
those guys see it.

>> > I found some hack that should work on complaining compilers. I will
>> > see the results of regression test today.  As for creating separate
>> > brunch for Boost.Test development, I do not really mind. But I
>> > believe it will create an extra headache for regression testers (and
>> > me).
>>
>> Not if it's automated.
>
> What you intend to automate?

Checking out the right branched material and starting the tests.

>> > Essentially we will need to have two copies of development
>> > tree.
>>
>> I doubt it.  How many libraries does Boost.Test depend on?  Are you
>> sure we can't just do this with branched copies of boost/test and
>> libs/test?
>
> I am quite sure, that it would be much easier to have separate development
> tree than to support subset needed for Boost.Test. It's much bigger that you
> imagine. And it's growing.

Even so, you would be developing a branch of your code against the
current CVS state of the rest of Boost, right?  I still don't see why
a 2nd copy of all of Boost should be needed.

>> > And run Boost.Test unit test in a separate tree. I will need
>> > to keep moving files back and forth 2 branches.
>>
>> Better to take the effort to be responsible for not breaking things
>> than to develop quickly and dangerously when your library is a
>> correctness bottleneck for so many others.
>
> Do you have any grounds to say that I develop quickly of
> dangerously?

I'm sorry, I didn't mean to imply that.  I meant that when so many
other libraries' tests are dependent on yours, any substantial change
you make that can't be widely tested beforehand is dangerous.  It's
better to move slowly if that's what it takes.

> I was working on this modifications for more than a two month before
> committing it.

At least the timing is OK; we can afford a little breakage now,
before we get into a new release cycle.

>> > Also I wonder how it will interact with release procedure.  You may
>> > noticed that I am trying to introduce modification in Boost.Test in
>> > "packages", meaning I do not do code modifications all the time. I am
>> > not sure that several days of "no regression test on some
>> > compilers", worth all that trouble.
>>
>> I think you underestimate the problems it causes, and probably also
>> how long the particular problem in question has existed in the
>> codebase (I think it's been over a week).  Many people have been
>> talking about trying to shorten the time it takes to get test results
>> for any particular library.  To go from 12-24 hours to "several days"
>> is probably the wrong direction.
>
> Once I start "modification period" I am fixing library issues
> ASAP. It takes longer to figure out how to find workaround for
> compiler deficiency, especially since I do not have an access to it.

Sure thing.

> Gennadiy.
>
> P.S. Could guys who support metacom development tree update it with -d.
> There is directory missing under libs/test/test

Again, a separate posting or direct email might be advisable.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com