| 28 | | Some requirements and notes: |
| 29 | | |
| 30 | | * `XXXX` must be decided ''before'' we begin compiling, whereas `ZZZZ` |
| | 28 | Some notes: |
| | 29 | |
| | 30 | * `XXXX` must be decided ''before'' we begin compiling, because we have to generate the `Paths_P.hs` file that is compiled along with the package, whereas `ZZZZ` is only available ''after'' we have compiled the package. |
| | 31 | * `ZZZZ` is not uniquely determined by the compilation inputs (see #4012), although in the future we hope it will be |
| | 32 | * It is desirable that when two packages have identical `YYYY` values, then they are compatible, even if they were built on separate systems. Note that this is not guaranteed even if `YYYY` is a deterministic function of the compilation inputs, because `ZZZZ` is non-deterministic (previous point). Hence `YYYY` must be dependent on `ZZZZ`. |
| | 33 | |
| | 34 | Our proposal: |
| | 35 | |
| | 36 | * We define a new ''Cabal Hash'' that hashes the compilation inputs (the `LocalBuildInfo` and the contents of the source files) |
| | 37 | * `XXXX` is a GUID. |
| | 38 | * Why not use the ''Cabal Hash''? We could, but then there could conceivably be a clash. |
| | 39 | * `YYYY` is the combination of the ''Cabal Hash'' and `ZZZZ` (concatenated) |
| | 40 | * `ZZZZ` is recorded in the package database. When two packages have identical `ZZZZ`s then they are interface-compatible, and the user might in the future want to change a particular dependency to use a different package but the the same `ZZZZ`. We do not want to make this change automatically, because even when two packages have identical `ZZZZ`s, they may have different behaviour (e.g. bugfixes). |
