[project @ 1998-03-03 04:45:06 by reid]

[ghc-hetmet.git] / CVS-CHEAT-SHEET

diff --git a/CVS-CHEAT-SHEET b/CVS-CHEAT-SHEET
index f559f99..42b47dd 100644 (file)
--- a/CVS-CHEAT-SHEET
+++ b/CVS-CHEAT-SHEET
@@ -51,15 +51,15 @@ Using CVS for the First Time
   tree you'll be working on.  The directory structure looks like this:
 
        fptools/ghc             GHC
-       fptools/hslibs          Haskell Libraries
        fptools/happy           Happy
        fptools/haggis          Haggis
        fptools/green-card      Green Card
        fptools/nofib           Nofib test suite
+       fptools/hdirect         IDL-to-Haskell compiler
        fptools/common-rts      GHC/Hugs combined run-time system
 
   For each directory, there's a mailing list: fp-cvs-ghc,
-  fp-cvs-hslibs etc.  Everyone on the mailing list is sent a message
+  fp-cvs-nofib etc.  Everyone on the mailing list is sent a message
   automatically by CVS whenever someone checks in a change, this helps
   to keep track of what's going on when several people are working on
   related stuff.  Ask the CVS meister to put you on the relevant
@@ -100,11 +100,11 @@ Checking Out a Source Tree
   You can call the fptools directory whatever you like, CVS won't mind.
 
        $ cd <directory>
-       $ cvs checkout ghc hslibs happy
+       $ cvs checkout ghc happy
 
   The second command here checks out the relevant modules you want to
-  work on.  For a GHC build, for instance, you need at least ghc and
-  hslibs.
+  work on.  For a GHC build, for instance, you need at least the ghc
+  module (in fact you can get away with just that).
 
 
 Committing Your Changes
@@ -175,6 +175,48 @@ Committing Your Changes
   For a multiple-file change, you should still get only *one* message.
 
 
+Updating Your Source Tree
+-------------------------
+
+It can be tempting to cvs update just part of a source tree to bring
+in some changes that someone else has made, or before committing your
+own changes.  This is NOT RECOMMENDED!  Quite often changes in one
+part of the tree are dependent on changes in another part of the tree
+(the mk/*.mk files are a good example where problems crop up quite
+often).  Having an inconsistent tree is a major cause of headaches.
+
+So, to avoid a lot of hassle, follow this recipe for updating your
+tree:
+
+$ cd fptools
+$ cvs update -Pd 2>&1 | tee log
+
+Look at the log file, and fix any conflicts (denoted by a 'C' in the
+first column).  Next for every build tree you have pointing at this
+source tree, you need to update the links in case any new files have
+appeared:
+
+$ cd <build-tree>
+$ lndir <source-tree>
+
+Some files might have been removed, so you need to remove the links
+pointing to these non-existent files:
+
+$ find . -xtype l -exec rm '{}' \;
+
+And finally, re-configure to take into accound any changes in
+mk/config.mk.in.
+
+$ ./configure
+
+To be *really* safe, you should do
+
+$ gmake boot && gmake all
+
+from the top-level, to update the dependencies and build any changed
+files.
+
+
 General Hints
 -------------
 
@@ -195,7 +237,7 @@ General Hints
 
 * To check out extra bits into an already-checked-out tree, use the
   following procedure.  Suppose you have a checked-out fptools tree containing
-  just ghc and hslibs, and you want to add nofib to it:
+  just ghc, and you want to add nofib to it:
 
        cd fptools
        cvs checkout nofib