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