• Edward Z. Yang's avatar
    Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
    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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
    b083151f
Register.hs 19.1 KB