Move "package key" generation to GHC
Currently in GHC 7.10, we have the following situation:
- Cabal computes a package key, which in practice (since no one is using Backpack in the wild) is a Merkle tree of the versions of each of the dependencies of the package.
- This package key is passed to GHC via
-this-package-key - GHC handles the package key opaquely
Now, in recent Backpack implementation, we need GHC to be able to compute package keys. (The concrete case: you're type-checking an interface file of an indefinite package, where you want to instantiate it with some assignment of its holes: instantiating those holes you need to instantiate any package keys mentioned in the interface, in which case you really want to be able to compute the hash.) So I want to move package key generation to GHC.
The primary implication is this: does Cabal continue to generate package keys? If it doesn't, we should revert from -this-package-key back to -package-name from the previous version (but maybe renamed because this name was bad). GHC then computes a package key based on -package-name and the explicitly mentioned -package dependencies, and Cabal reads it out with something akin to --abi-hash. If it does, we need to ensure GHC and Cabal's package key algorithms stay synchronized. I personally lean towards the first option.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |