|
|
# GHC Commentary: Libraries
|
|
|
|
|
|
|
|
|
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).
|
|
|
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.
|
|
|
|
|
|
|
|
|
The 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`.)
|
|
|
|
|
|
|
|
|
Every installation of GHC includes the Boot Packages.
|
|
|
|
|
|
## Zero-boot packages
|
|
|
|
|
|
|
|
|
The **Zero-boot Packages** are a small subset of the boot packages. Since GHC's source code imports the boot packages, *even the bootstrap compiler must have the boot packages available*. But 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. 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.) The bootstrap compiler is expected to have all other (non-zero-) boot packages already installed.
|
|
|
|
|
|
|
|
|
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.
|
|
|
You can see exactly which versions of what packages GHC depends on by looking in `$(TOP)/compiler/ghc.cabal.in`.
|
|
|
|
|
|
|
|
|
The current Zero-boot packages are:
|
|
|
|
|
|
- `Cabal`: we frequently update Cabal and GHC in sync
|
|
|
- `hpc`
|
|
|
- `extensible-exceptions`
|
|
|
Every installation of GHC includes the Boot Packages.
|
|
|
|
|
|
## Classifying the boot packages
|
|
|
|
... | ... | @@ -44,6 +32,27 @@ The current classification of packages is: |
|
|
- COUPLED: `base`
|
|
|
- INDEPENDENT: all other packages
|
|
|
|
|
|
## Zero-boot packages
|
|
|
|
|
|
|
|
|
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.)
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.)
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
The current Zero-boot packages are:
|
|
|
|
|
|
- `Cabal`: we frequently update Cabal and GHC in sync
|
|
|
- `hpc`
|
|
|
- `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.
|
|
|
|
|
|
## Boot packages dependencies
|
|
|
|
|
|
- At the root of the hierarchy we have **`ghc-prim`**. As the name implies, this package contains the most primitive types and functions. It only contains a handful of modules, including `GHC.Prim` (which contains `Int#`, `+#`, etc) and `GHC.Bool`, containing the `Bool` datatype.
|
... | ... | |