Changes between Version 17 and Version 18 of Commentary/Libraries


Ignore:
Timestamp:
Aug 28, 2009 12:43:33 PM (5 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Libraries

    v17 v18  
    11= GHC Commentary: Libraries = 
    22 
    3 All GHC build trees contain a set of libraries, called the '''Boot Packages'''.  These are the libraries that GHC's source code imports.  Obviously you need the boot packages to build GHC at all (whether the stage-1 or stage-2 compiler). 
     3All GHC build trees contain a set of libraries, called the '''Boot Packages'''.  These are the libraries that GHC's source code imports.  Obviously you need the boot packages to build GHC at all. 
    44 
    55The Boot Packages, along with the other subcomponents of the GHC build system, are in the file `packages` in a GHC tree. To get a list of them, you can run `make show VALUE=PACKAGES` in a configured GHC build tree.  (This variable is set in `$(TOP)/ghc.mk`.) 
     
    99Every installation of GHC includes the Boot Packages. 
    1010 
    11 == Zero-boot packages == 
    12  
    13 Since GHC's source code imports the boot packages, ''even the bootstrap compiler must have the boot packages available''.  (Or, more precisely, all the types and values that are imported must be available from some package in the bootstrap compiler; the exact set of packages does not need to be identical.) 
    14  
    15 For the most part we simply assume that the bootstrap compiler already has the boot packages installed.  The '''Zero-boot Packages''' are a set of packages for which this assumption does not hold.  For example, for certain fast-moving boot packages (eg Cabal), we don't want to rely on the user having installed a bang-up-to-date version of the package.   
    16  
    17 So we begin the entire build process by installing the zero-boot packages in the bootstrap compiler.  (This installation is purely local to the build tree.)   
    18  
    19 As time goes on, a Zero-boot package may become an ordinary boot package, because the bootstrap compiler is expected to have (a sufficiently up to date) version of the package already. 
    20  
    21 The current Zero-boot packages are: 
    22  * `Cabal`: we frequently update Cabal and GHC in sync 
    23  * `hpc` 
    24  * `extensible-exceptions` 
    2511 
    2612== Classifying the boot packages == 
     
    3925  * COUPLED: `base` 
    4026  * INDEPENDENT: all other packages 
     27 
     28== Zero-boot packages == 
     29 
     30Since GHC's source code imports the boot packages, ''even the bootstrap compiler must have the boot packages available''.  (Or, more precisely, all the types and values that are imported must be available from some package in the bootstrap compiler; the exact set of packages does not need to be identical.) 
     31 
     32For the most part we simply assume that the bootstrap compiler already has the boot packages installed.  The '''Zero-boot Packages''' are a set of packages for which this assumption does not hold.  For example, for certain fast-moving boot packages (eg Cabal), we don't want to rely on the user having installed a bang-up-to-date version of the package.   
     33 
     34So we begin the entire build process by installing the zero-boot packages in the bootstrap compiler.  (This installation is purely local to the build tree.)   
     35 
     36As time goes on, a Zero-boot package may become an ordinary boot package, because the bootstrap compiler is expected to have (a sufficiently up to date) version of the package already. 
     37 
     38The current Zero-boot packages are: 
     39 * `Cabal`: we frequently update Cabal and GHC in sync 
     40 * `hpc` 
     41 * `extensible-exceptions`: this is a shim that provides an API to older versions of GHC that is compatible with what the current `base` package now exports.  So, unusually, `extensible-exceptions` is a zero-boot package, but not a boot package. 
    4142 
    4243== Boot packages dependencies ==