1<div id="Builds"></div> 2<div class="header"> 3<p> 4Next: [[cvs: Special Files#Special Files|Special Files]], Previous: [[cvs: Tracking third-party sources#Tracking third-party sources|Tracking sources]], Up: [[cvs#Top|Top]] |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p> 5</div> 6<div id="How-your-build-system-interacts-with-CVS"></div> 7== How your build system interacts with CVS == 8<div id="index-Builds"></div> 9<div id="index-make"></div> 10 11As mentioned in the introduction, <small>CVS</small> does not 12contain software for building your software from source 13code. This section describes how various aspects of 14your build system might interact with <small>CVS</small>. 15 16One common question, especially from people who are 17accustomed to <small>RCS</small>, is how to make their build get 18an up to date copy of the sources. The answer to this 19with <small>CVS</small> is two-fold. First of all, since 20<small>CVS</small> itself can recurse through directories, there 21is no need to modify your ‘<tt>Makefile</tt>’ (or whatever 22configuration file your build tool uses) to make sure 23each file is up to date. Instead, just use two 24commands, first <code>cvs -q update</code> and then 25<code>make</code> or whatever the command is to invoke your 26build tool. Secondly, you do not necessarily 27''want'' to get a copy of a change someone else made 28until you have finished your own work. One suggested 29approach is to first update your sources, then 30implement, build and 31test the change you were thinking of, and then commit 32your sources (updating first if necessary). By 33periodically (in between changes, using the approach 34just described) updating your entire tree, you ensure 35that your sources are sufficiently up to date. 36 37<div id="index-Bill-of-materials"></div> 38One common need is to record which versions of which 39source files went into a particular build. This kind 40of functionality is sometimes called <em>bill of 41materials</em> or something similar. The best way to do 42this with <small>CVS</small> is to use the <code>tag</code> command to 43record which versions went into a given build 44(see [[cvs: Revisions#Tags–Symbolic revisions|Tags]]). 45 46Using <small>CVS</small> in the most straightforward manner 47possible, each developer will have a copy of the entire 48source tree which is used in a particular build. If 49the source tree is small, or if developers are 50geographically dispersed, this is the preferred 51solution. In fact one approach for larger projects is 52to break a project down into smaller 53separately-compiled subsystems, and arrange a way of 54releasing them internally so that each developer need 55check out only those subsystems which they are 56actively working on. 57 58Another approach is to set up a structure which allows 59developers to have their own copies of some files, and 60for other files to access source files from a central 61location. Many people have come up with some such a 62system using features such as the symbolic link feature 63found in many operating systems, or the <code>VPATH</code> 64feature found in many versions of <code>make</code>. One build 65tool which is designed to help with this kind of thing 66is Odin (see 67<code>ftp://ftp.cs.colorado.edu/pub/distribs/odin</code>). 68 69 70---- 71 72<div class="header"> 73<p> 74Next: [[cvs: Special Files#Special Files|Special Files]], Previous: [[cvs: Tracking third-party sources#Tracking third-party sources|Tracking sources]], Up: [[cvs#Top|Top]] |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p> 75</div> 76This document was generated on <i>a sunny day</i> using [http://www.nongnu.org/texi2html/ <i>texi2html</i>]. 77