Re: Modelling project dependencies in CVS

[Paul Sander]

"My tool of choice for software reuse was the editor, until I inherited
60,000 lines of code from someone who felt the same way.  Now my tool of
choice for software reuse is the linker."  -- me, 1988

The solution to your problem is not to use CVS to model your subsystem
dependencies, but rather use your build system.  Create a baseline build
that contains your A library and write your Makefiles (or whatever) to
use that rather than requiring all of your developers to fetch and build it
in their sandboxes.

This is usually accomplished by building search paths for your compiler,
which can be done is several ways.  Examples are to use well-known places
in the filesystem, set environment variables, use a publish/subscribe
method in your build infrastructure, use Make's VPATH feature, switch
build tool to something like Cook (which is better at autodiscovery than
Make), and others.

My personal favorite method is to use a publish/subscribe meechanism in
combination with a tightly controlled standard environment.  That sounds
nasty but it gives a good repeatable process with great flexibility in all
the right places.  Take a look at http://www.wakawaka.com/source.html for
some tools that might help you, specifically buildref and envctrl.

--- Forwarded mail from address@hidden

i have three projects A, B and C, that are all under current 
development. Project A is some kind of a library, and projects B and C 
depend on it. Now i see only two solutions to this, but both of them 
seem to be really nasty:

1. Project A exists three times in the repository, once as a module 
(since it is under development itself), and once as subdir of projects B 
and C each. But this would cause big trouble to keep these three 
versions consistent and up to date.

2. Project A only exists as its own module, and projects B/C refer to A 
in the kind of ../projectA/, which means they contain paths leading 
outside the working copy. This would force everyone who wants to work on 
projects B/C to checkout A as "projectA" in the same folder.

I think there must be something better, but I don't see it ...

--- End of forwarded message from address@hidden