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
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
> > 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.
P.S. Could guys who support metacom development tree update it with -d.
There is directory missing under libs/test/test
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk