[boost] Re: Cvs tag dependency

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-30 19:18:46

"Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]> writes:

>> "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]> writes:
>> 
>> > Hi,
>> >
>> > Inn a light of recent discussion on earlier freezing, I 
>> have following
>> > question/proposition:
>> >
>> > Is it exist in Boost.Build or could we add feature that allow us to 
>> > specify cvs tag dependency as a dependency grist?
>> 
>> I _think_ what you're proposing is interesting, but the means 
>> of getting there may be completely inappropriate for 
>> Boost.Build, if I understand it at all.  Why don't you try to 
>> say what you're trying to accomplish without trying to design 
>> the Boost.Build feature? 
>
> I want to be able to use regression testing facility not only for HEAD cvs
> state.

That's already possible; just check out the CVS state you want to
test (?)

>> Are you trying to get cvs checkout actions into the build system?
>
> Namely. I want build system be aware about different versions of
> files/components and want to be able to specify which version I
> prefer to use for this particular test.
>
>> If so, why? What's wrong with doing
>> 
>>        cvs update -rwhatever_tag
>> before kicking off the test?
>
> Nothing. I just want it happened automatically on a computer that performs
> regression testing, depends on a rule defined in a Jamfile.

Do you mean that you want _remote_ machines to test against various
CVS states?

If so, it seems that you're right: it would be extremely difficult.
It seems to me that any test could request different states of
various libraries, which would either require many separate checkouts
of the same Boost CVS tree, or would induce a great deal of churn in
the testing process as header files changed states.  Furthermore,
it's not really clear what it means to test against a particular tag
for a given library, when that library may depend on other libraries.

I think it would be better to stick with testing models we can fully
understand and implement for now ;-)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com