Gennadiy Rozental writes:
There may be some differences between metacom and mine "last night". Check now. I do not know what is the version of intel compiler
It's encoded in the toolset name -- intel-win32-7.1-vc6. ^^^
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?
Put on the TODO list.
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.
For the purpose of testing, it doesn't matter whether you have the whole tree on the branch, or just a subset of it. As long as it's only the test and config libraries that are being tested on that branch, we can afford it. [...]
P.S. Could guys who support metacom development tree update it with -d. There is directory missing under libs/test/test
We remove all the sources and do a full checkout on every cycle, so whatever problems you might have, they are not caused by a missing directory, if the latter is in the CVS, of course. -- Aleksey Gurtovoy MetaCommunications Engineering