mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-11 23:08:30 +01:00
Remove code explanation
This commit is contained in:
parent
fdc0554a0d
commit
83f8bf083f
42
README.md
42
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.)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user