From 83f8bf083f89ec11d197b4eed6f57de0fde4cda7 Mon Sep 17 00:00:00 2001 From: Michael Snoyman Date: Mon, 23 Mar 2015 20:09:23 +0200 Subject: [PATCH] Remove code explanation --- README.md | 42 ------------------------------------------ 1 file changed, 42 deletions(-) diff --git a/README.md b/README.md index 47f46a1f..65a7dc66 100644 --- a/README.md +++ b/README.md @@ -96,45 +96,3 @@ The following describes at a high level the series of steps for processing 1. Load up most recent build plan 2. Convert build plan into constraints for next build 3. Continue from step (3) above - -## Code explanation - -We start off with *constraints*. Constraints state things like "package X has a -given version range," who the maintainer is for a package, the description of -the system/compiler being used, etc. `BuildConstraints` describes the build as -a whole, whereas `PackageConstraints` describes the constraints on an -individual package. - -There are two primary ways of getting a `BuildConstraints`. -`defaultBuildConstraints` inspects the first GHC in the PATH environment variable to -determine GHC version, core packages, core tools, etc. It then uses the -`Stackage.Config` module to extract information on additional packages to be -installed. The secondary approach is in `Stackage2.UpdateBuildPlan`, which will be -discussed later. - -`BuildConstraints` does not specify a build completely. That is given by a -`BuildPlan`, which is similarly broken down into `BuildPlan` and `PackagePlan`. -In order to get a `BuildPlan`, we need two pieces of information: the -`BuildConstraints`, and a package index. The package index (usually downloaded -from Hackage) is a collection of all of the cabal files available. - -By applying a `BuildConstraints` to a package index (via `newBuildPlan`), we -get a proposed `BuildPlan`. There is no guarantee that this `BuildPlan` is -valid. To validate it, we use `checkBuildPlan`. A `BuildPlan` is an instance of -both `ToJSON` and `FromJSON`, and therefore can be serialized to a file for -later use. - -When dealing with LTS Haskell, we want to be able to take a `BuildPlan`, and -update to a newer `BuildPlan` that keeps all packages at the same major -version. `updateBuildConstraints` turns a `BuildPlan` into a new -`BuildConstraints` with that restriction, and `updateBuildPlan` applies -`newBuildPlan` to that result. As mentioned previously: this is *not* a -validated result, and therefore `checkBuildPlan` must be used. - -A `BuildPlan` can be acted on. This is done to check that all packages compile -together, run relevant test suites, test Haddock documentation is correct, and -produce as artifacts both a self-contained GHC binary package database and a -set of Haddock documentation. (Not yet implemented.) - -A `BuildPlan` may be converted into a bundle to be uploaded to Stackage Server. -(Not yet implemented.)