DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH
 

(cvs.info.gz) Builds

Info Catalog (cvs.info.gz) Tracking sources (cvs.info.gz) Top (cvs.info.gz) Special Files
 
 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 ( 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 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').
 
Info Catalog (cvs.info.gz) Tracking sources (cvs.info.gz) Top (cvs.info.gz) Special Files
automatically generated byinfo2html