"Rozental, Gennadiy" <gennadiy.rozental@thomson.com> 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.
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.
Dave Abrahams
Gennadiy.
"Rozental, Gennadiy" <gennadiy.rozental@thomson.com> writes:
"Rozental, Gennadiy" <gennadiy.rozental@thomson.com> 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
On 06/30/2004 07:18 PM, David Abrahams wrote: [snip]
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. It would be similar to dependency checking for rpm or debian packages. For example,
pkgA~1.1~ depends on: pkgB~1.1~ pkgC~2.3~ and, for example, pkgB~1.1~ depends on fileX~1.1~ fileY~1.4~ where pkg<name> indicates a package and file<name> means an actual file, and ~<unsigned>.<unsigned>~ signifies the version of either package or file depending on what precedes it. Now, how you do that with tags, is another question, but it certainly can be done with the method I proposed earlier using release.log's. In that case, instead of pkgA, there would be: pkgA.release.log.~1.1~ where 1.1 is just the version number of the release.log file.
participants (3)
-
David Abrahams -
Larry Evans -
Rozental, Gennadiy