GNU Info

(cvs.info)Builds

---

Next: Special Files Prev: Tracking sources Up: Top

---

Enter node , (file) or (file)node

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 (Note: Tags).

   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 are 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').