@@ -96,45 +96,3 @@ The following describes at a high level the series of steps for processing
96961. Load up most recent build plan
97972. Convert build plan into constraints for next build
98983. Continue from step (3) above
99−
100−## Code explanation
101−
102−We start off with *constraints*. Constraints state things like "package X has a
103−given version range," who the maintainer is for a package, the description of
104−the system/compiler being used, etc. `BuildConstraints` describes the build as
105−a whole, whereas `PackageConstraints` describes the constraints on an
106−individual package.
107−
108−There are two primary ways of getting a `BuildConstraints`.
109−`defaultBuildConstraints` inspects the first GHC in the PATH environment variable to
110−determine GHC version, core packages, core tools, etc. It then uses the
111−`Stackage.Config` module to extract information on additional packages to be
112−installed. The secondary approach is in `Stackage2.UpdateBuildPlan`, which will be
113−discussed later.
114−
115−`BuildConstraints` does not specify a build completely. That is given by a
116−`BuildPlan`, which is similarly broken down into `BuildPlan` and `PackagePlan`.
117−In order to get a `BuildPlan`, we need two pieces of information: the
118−`BuildConstraints`, and a package index. The package index (usually downloaded
119−from Hackage) is a collection of all of the cabal files available.
120−
121−By applying a `BuildConstraints` to a package index (via `newBuildPlan`), we
122−get a proposed `BuildPlan`. There is no guarantee that this `BuildPlan` is
123−valid. To validate it, we use `checkBuildPlan`. A `BuildPlan` is an instance of
124−both `ToJSON` and `FromJSON`, and therefore can be serialized to a file for
125−later use.
126−
127−When dealing with LTS Haskell, we want to be able to take a `BuildPlan`, and
128−update to a newer `BuildPlan` that keeps all packages at the same major
129−version. `updateBuildConstraints` turns a `BuildPlan` into a new
130−`BuildConstraints` with that restriction, and `updateBuildPlan` applies
131−`newBuildPlan` to that result. As mentioned previously: this is *not* a
132−validated result, and therefore `checkBuildPlan` must be used.
133−
134−A `BuildPlan` can be acted on. This is done to check that all packages compile
135−together, run relevant test suites, test Haddock documentation is correct, and
136−produce as artifacts both a self-contained GHC binary package database and a
137−set of Haddock documentation. (Not yet implemented.)
138−
139−A `BuildPlan` may be converted into a bundle to be uploaded to Stackage Server.
140−(Not yet implemented.)