From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-05-22 15:29:47
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk