CVS--Concurrent Versions System v1.12.12.1: How your build system interacts with CVS

</tr></table>

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 [[CVS--Concurrent Versions System v1.12.12.1: Revisions#SEC50|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 ).

This document was generated by Derek Price on July, 20 2005 using texi2html 1.77.