14. How your build system interacts with CVS
As mentioned in the introduction, CVS does not
contain software for building your software from source
code. This section describes how various aspects of
your build system might interact with CVS.
One common question, especially from people who are
accustomed to RCS, is how to make their build get
an up to date copy of the sources. The answer to this
with CVS is two-fold. First of all, since
CVS itself can recurse through directories, there
is no need to modify your `Makefile' (or whatever
configuration file your build tool uses) to make sure
each file is up to date. Instead, just use two
commands, first cvs -q update and then
make or whatever the command is to invoke your
build tool. Secondly, you do not necessarily
want to get a copy of a change someone else made
until you have finished your own work. One suggested
approach is to first update your sources, then
implement, build and
test the change you were thinking of, and then commit
your sources (updating first if necessary). By
periodically (in between changes, using the approach
just described) updating your entire tree, you ensure
that your sources are sufficiently up to date.
One common need is to record which versions of which
source files went into a particular build. This kind
of functionality is sometimes called bill of
materials or something similar. The best way to do
this with CVS is to use the tag command to
record which versions went into a given build
(see section Tags–Symbolic revisions).
Using CVS in the most straightforward manner
possible, each developer will have a copy of the entire
source tree which is used in a particular build. If
the source tree is small, or if developers are
geographically dispersed, this is the preferred
solution. In fact one approach for larger projects is
to break a project down into smaller
separately-compiled subsystems, and arrange a way of
releasing them internally so that each developer need
check out only those subsystems which they are
actively working on.
Another approach is to set up a structure which allows
developers to have their own copies of some files, and
for other files to access source files from a central
location. Many people have come up with some such a
system using features such as the symbolic link feature
found in many operating systems, or the VPATH
feature found in many versions of make. One build
tool which is designed to help with this kind of thing
is Odin (see
ftp://ftp.cs.colorado.edu/pub/distribs/odin).
