• Edward Z. Yang's avatar
    Refactor Cabal around the idea of "library names". · f47732a5
    Edward Z. Yang authored
    In GHC 7.10, Cabal always generate package keys, including in
    cases where Backpack was involved (e.g. --instantiated-with).
    In fact, in these case, GHC needs to be able to generate the
    package key (because it will often make a substitution on the
    instantiation, and needs to know if this identity coincides with
    anything else we've seen previously).
    Thus, we introduce a new notion, the 'LibraryName', which
    is JUST the non-Backpack portion of a package key.  For ordinary
    packages that are definite, a 'LibraryName' is simply
    the 'PackageId' plus 'PackageKey'; for indefinite Backpack packages,
    when a package gets instantiatied, it may end up with different
    'PackageKey's even though the 'LibraryName' stays the same.
    'LibraryName's can be computed purely by Cabal.
    This patch:
        - Defines library name, which are the source package ID plus
          a hash of all the source package ID and the library names of external,
          textual dependencies,
        - Redefines the package key to be JUST the hash portion of a
          library name, in the case that Backpack is not used,
        - Records the library name in InstalledPackageInfo.
    Note: the source package ID is included both externally (so the library
    name is a useful handle to refer to package) and internally (so the
    hash can stand alone as the package key.)
    A major refactoring which is part of this commit is moving package keys/library
    names from LocalBuildInfo to LibComponentBuildInfo.  If you have an LBI, you can
    still extract a package key/library name using the new
    localPackageKey/localLibraryName function (which looks through the
    ComponentBuildInfos of a LocalBuildInfo for the library in question).  This is
    conceptually cleaner for two reasons:
        1. Only dependencies of the *library* are counted as part
        of the library name, as opposed to *all* dependencies which
        we previously used.
        2. A library name doesn't really mean much for an executable,
        or a test suite, since no one else will have to link against
        them.  So we can fall back on something simpler.
    A more minor refactoring is the 'LibraryName' type, which was
    previously defined by LocalBuildInfo and generally looked something
    like "HSprocess-0.1-XXXX".  We change the meaning of 'LibraryName'
    to be "process-0.1-XXXX" (thus we have to insert some HS additions
    in the code) and eliminate componentLibraries, thus assuming that
    there is only ONE Haskell library (which was the case.)  So
    we remove a little bit of generality and in return get code
    that is much easier to read.  (The only downside is GHC's hack
    to split DLLs into multiples has to be adjusted slightly, but
    this is not a big price to pay.)
    Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>