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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-05-22 11:20:22

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

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

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

There may be some differences between metacom and mine "last night". Check
now. I do not know what is the version of intel compiler and couldn't switch
to hack workaround for it.
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 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?

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

> > 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 was working on this modifications for more than a two month before
committing it.

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

Gennadiy.

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