Changes between Version 8 and Version 9 of Debugging/InstallingPackagesInplace


Ignore:
Timestamp:
Sep 20, 2010 9:30:17 AM (4 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Debugging/InstallingPackagesInplace

    v8 v9  
    77Every GHC, including the inplace one, comes with the [wiki:Commentary/Libraries boot libraries].  But sometimes a test case will require the installation of some packages from Hackage.  There are two routes. 
    88 
    9 == Plan A: Cabal is up to date == 
     9== Plan A: use [http://hackage.haskell.org/trac/hackage/wiki/CabalInstall cabal install] == 
    1010 
    11 If your installed `cabal` is sufficiently up to date, you can just use [http://hackage.haskell.org/trac/hackage/wiki/CabalInstall cabal install]: 
     11This method is quick and easy, but can fail if your `cabal` program is out of date with respect to the GHC version you are building.  Here's how to install a library against a GHC build tree: 
     12 
    1213{{{ 
    13 cabal install --with-ghc=<inplace-ghc> --global <package> 
     14cabal install --with-ghc=<inplace-ghc> <package> 
    1415}}} 
    1516where `<inplace ghc>` is the path to your inplace GHC (usually `$(TOP)/inplace/bin/ghc-stage2`), and <package> is the name of the package. 
    1617 
    1718Points to note: 
    18  * This will install the package in your home directory (e.g. somewhere under `~/.cabal/lib` on a Unix system) , so you'll probably want to remove it by hand when you've finished. 
    19  
    20  * The `--global` says to register the package in the global database, which for the inplace compiler is something like `$(TOP)/inplace/lib/package.conf.d/`.  The default is `--local` which registers the package in a (compiler-version-specific) directory in your home directly.  The danger is that you you have many builds, the "compiler-version-specific" part might not be enough to keep all your builds separate. 
     19 * This will install the package in your home directory (e.g. somewhere under `~/.cabal/lib` on a Unix system), and it will register the package in your private package database, so you'll probably want to remove and unregister it by hand when you've finished. 
    2120 
    2221Plan A can fail, because sometimes Cabal changes, so you might get a message like 
     
    2625In that case you need to use the Cabal code that comes with the new version of GHC (ie the one in your build tree).  So use Plan B. 
    2726 
    28 == Plan B: Cabal is out of date == 
     27== Plan B: use the Cabal library bundled with GHC == 
     28 
     29This method is slightly more work, but it does have the advantage of not installing anything in your home directory that you have to go and remove later. 
    2930 
    3031Go to a directory where you are happy to keep the newly-downloaded code. 
     
    4647 * It is important to compile `Setup.lhs` with your shiny new ''inplace'' GHC, not your installed GHC.  Your inplace GHC has the most up-to-date Cabal library, and that is what you want to link `Setup.lhs` against. 
    4748 
    48  * The `--global` flag has the same purpose as in Plan A 
     49 * The `--global` flag instructs Cabal to register the package in the database in your build tree, rather than the one in your home directory (`~/.ghc/...`).  In fact, `--global` is actually unnecesary (it's the default), but just in case the default changes in the future it's a good idea to get in the habit of saying whether you want `--global` or `--user`. 
    4950  
    5051 * The `--inplace` flag to register tells Cabal not to copy the compiled package, but rather to leave it right where it is, and register this location in the package database in your GHC build tree