[GHC] #10566: Move "package key" generation to GHC

[GHC]

#10566: Move "package key" generation to GHC
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                   Owner:  ezyang
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Package system    |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:  Phab:D1056
-------------------------------------+-------------------------------------

Comment (by Edward Z. Yang <ezyang@…>):

 In [changeset:"f9687caf337d409e4735d5bb4cf73a7dc629a58c/ghc"
 f9687caf/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="f9687caf337d409e4735d5bb4cf73a7dc629a58c"
 Library names, with Cabal submodule update

 A library name is a package name, package version, and hash of the
 version names of all textual dependencies (i.e. packages which were
 included.) A library
 name is a coarse approximation of installed package IDs, which are
 suitable for
 inclusion in package keys (you don't want to put an IPID in a package key,
 since
 it means the key will change any time the source changes.)

     - We define ShPackageKey, which is the semantic object which
       is hashed into a PackageKey.  You can use 'newPackageKey'
       to hash a ShPackageKey to a PackageKey

     - Given a PackageKey, we can lookup its ShPackageKey with
       'lookupPackageKey'.  The way we can do this is by consulting
       the 'pkgKeyCache', which records a reverse mapping from
       every hash to the ShPackageKey.  This means that if you
       load in PackageKeys from external sources (e.g. interface
       files), you also need to load in a mapping of PackageKeys
       to their ShPackageKeys so we can populate the cache.

     - We define a 'LibraryName' which encapsulates the full
       depenency resolution that Cabal may have selected; this
       is opaque to GHC but can be used to distinguish different
       versions of a package.

     - Definite packages don't have an interesting PackageKey,
       so we rely on Cabal to pass them to us.

     - We can pretty-print package keys while displaying the
       instantiation, but it's not wired up to anything (e.g.
       the Outputable instance of PackageKey).

 Signed-off-by: Edward Z. Yang <ezyang at cs.stanford.edu>

 Test Plan: validate

 Reviewers: austin, bgamari

 Subscribers: thomie

 Differential Revision: https://phabricator.haskell.org/D1056

 GHC Trac Issues: #10566
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10566#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler