-
Edward Z. Yang authored
Today in Cabal, when you build and install a package, it is uniquely identified using an InstalledPackageId which is computed using the ABI hash of the library that was installed. There are few problems with doing it this way: - In a Nix-like world, we should instead uniquely identify build products by some sort of hash on the inputs to the compilation (source files, dependencies, flags). The ABI hash doesn't capture any of this! - An InstalledPackageId suggests that we can uniquely identify build products by hashing the source and dependencies of a package as a whole. But Cabal packages contain many components: a library, test suite, executables, etc. Currently, when we say InstalledPackageId, we are really just talking about the dependencies of the library; however, this is unacceptable if a Cabal package can install multiple libraries; we need different identifiers for each. - We've also needed to compute another ID, which we've called the "package key", which is to be used for linker symbols and type equality GHC-side. It is confusing what the distinction between this ID and InstalledPackageIds are; the main reason we needed another ID was because the package key was needed prior to compilation, whereas the ABI hash was only available afterwards. This patch replaces InstalledPackageId and PackageKey with a new identifier called ComponentId, which has the following properties: - It is computed per-component, and consists of a package name, package version, hash of the ComponentIds of the dependencies it is built against, and the name of the component. For example, "foo-0.1-abcdef" continues to identify the library of package foo-0.1, but "foo-0.1-123455-foo.exe" would identify the executable, and "foo-0.1-abcdef-bar" would identify a private sub-library named bar. - It is passed to GHC to be used for linker symbols and type equality. So as far as GHC is concerned, this is the end-all be-all identifier. - Cabal the library has a simple, default routine for computing a ComponentId which DOES NOT hash source code; in a later patch Duncan is working on, cabal-install can specify a more detailed ComponentId for a package to be built with. Here are some knock-on effects: - 'id' is a ComponentId - 'depends' is now a list of ComponentIds - New 'abi' field to record what the ABI of a unit is (as it is no longer computed by looking at the output of ghc --abi-hash). - The 'HasInstalledPackageId' typeclass is renamed to 'HasComponentId'. - GHC 7.10 has explicit compatibility handling with a 'compatPackageKey' (an 'ComponentId') which is in a compatible format. The value of this is read out from the 'key' field. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
b083151f