Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jul 24, 2015
  1. @23Skidoo


    23Skidoo authored
Commits on Jul 21, 2015
  1. @ezyang

    Refactor Cabal around the idea of "library names".

    ezyang 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: Edward Z. Yang <>
Commits on Jun 22, 2015
  1. @ezyang

    Drop pkgna_ prefix from package keys, c.f.…

    ezyang authored
    Signed-off-by: Edward Z. Yang <>
Commits on Mar 21, 2015
  1. @edsko

    Split the PackageInstalled class

    edsko authored
    Introduce a new superclass HasInstalledPackageId:
        class Package pkg => HasInstalledPackageId pkg where
          installedPackageId :: pkg -> InstalledPackageId
        class HasInstalledPackageId pkg => PackageInstalled pkg where
          installedDepends :: pkg -> [InstalledPackageId]
    Most functions that deal with the package index now just require
    HasInstalledPackageId; only the functions that actually require the
    dependencies still rely on PackageInstalled.
    The point is that a ConfiguredPackage/ReadyPackage/PlanPackage can reasonably
    be made an instance of HasInstalledPackageId, but not of PackageInstalled; that
    will be the topic of the next, much larger, pull request.
  2. @edsko

    Move PackageFixedDeps from Cabal to cabal-install

    edsko authored
    The fundamental difference between Cabal and cabal-install is that the former
    deals with installed libraries, and -- in principle -- knows about _library_
    dependencies only, whereas the latters deals with setup, executable, test-suite
    and benchmark dependencies in addition to library dependencies. Currently we
    classify all of these simply as 'dependencies' but that will change shortly.
    In this commit we take a first step towards this by moving the PackageFixedDeps
    class, which deals with dependencies of packages rather than installed
    libraries, from Cabal to cabal-install.
    The commit is pretty simple; we just move the type class and update import
    statements where necessary.
Commits on Mar 17, 2015
  1. @23Skidoo
  2. @23Skidoo

    80-col violations.

    23Skidoo authored
Commits on Mar 6, 2015
  1. @ezyang

    Put full package name and version in library names, fixes #2437.

    ezyang authored
    Signed-off-by: Edward Z. Yang <>
Commits on Jan 11, 2015
  1. @tibbe

    Merge branch 'old-binary' of

    tibbe authored
Commits on Jan 10, 2015
  1. @ezyang

    Fully specify package key format, so external tools can generate it.

    ezyang authored
    Signed-off-by: Edward Z. Yang <>
Commits on Jan 8, 2015
  1. @ttuegel

    D.Compat.Binary: backport binary generics to binary-0.5

    ttuegel authored
    GHC generics are used to derive binary instances for types appearing
    in the persistent build config, which requires GHC >= 7.2 and
    binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
    The missing module is Data.Binary.Generics, which we have copied from
    binary- to Distribution.Compat.Binary.Generics. To provide
    generic implementations for the Binary class, we also have to provide
    our own implementation, which is copied from binary- to
    Distribution.Compat.Binary.Class. The interface required by Cabal is
    exported from Distribution.Compat.Binary. This is only done if
    bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
    otherwise Distribution.Compat.Binary simply re-exports Data.Binary.
Commits on Nov 26, 2014
  1. @ezyang

    Preliminary support for compiling signature files, using --instantiat…

    ezyang authored
    There's no chrome here, but some of the guts for Cabal supporting compiling
    signatures.  The key UI is a new --instantiate-with flag for ./Setup (no support
    cabal-install side!) which properly modifies the package key, calculates extra
    hole dependencies for a package, and ensures an appropriately
    translated -sig-of is passed to GHC.  The UI here is supremely user-unfriendly:
    the intent is that users will use cabal-install to calculate these parameters
    for them.
    ToDo: Cabal's inconsistency check in ./Setup needs to be adjusted to be
    less zealous.
    Signed-off-by: Edward Z. Yang <>
Commits on Aug 30, 2014
  1. @ttuegel
Commits on Aug 27, 2014
  1. @dcoutts

    Merge pull request #2061 from dcoutts/master

    dcoutts authored
    Change rep of module re-exports, and do module re-export resolution ourselves in Cabal
  2. @ezyang

    Make Distribution.Simple.PackageIndex polymorphic in package storage.

    ezyang authored
    BC note: renamed type PackageIndex :: * to InstalledPackageIndex.
    The intent is to have cabal-install use this package index in order to
    track information about compilation in progress.  We introduce a new
    PackageInstalled type-class to keep track of data types which have their
    IDs and dependency graphs in InstalledPackageId.
    Signed-off-by: Edward Z. Yang <>
  3. @dcoutts

    Change rep of module re-exports, and do resolution ourselves

    dcoutts authored
    The initial support for module re-exports relied on ghc-pkg to resolve
    user-specified re-exports to references to specific installed packages.
    This resolution is something that can fail so it's better for Cabal to
    do it during the package configure phase.
    In addition, it is inconvenient in ghc-pkg to be doing this resolution,
    and it just seems fishy as a design. Also, the same ModuleExport type
    was being used both for user-specified source re-exports and also for
    the specific re-exports in the package db.
    This patch splits the type into two: one for source level, and one for
    resolved ones for use in the package db. The configure phase resolves
    one to the other.
    One minor change: it is now possible to re-export a module defined in
    the same package that is not itself exported (ie it's in other-modules,
    rather than exposed-modules). Previously for modules definied in the
    same package they had to be themselves exported. Of course for
    re-exports from other packages they have to be exposed.
Commits on Aug 4, 2014
  1. @ezyang

    Implement package keys, distinguishing packages built with different …

    ezyang authored
    Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
    would only be one instance of it in the installed packages database.  This
    posed problems for situations where you want a package compiled twice against
    different sets of dependencies: they could not both exist in the package
    Package keys are a hash of the package ID and package
    dependencies, which identify a package more uniquely than a package ID, but less
    uniquely than an installed package ID. Unlike installed package IDs, these can
    be computed immediately after dependency resolution, rather than after
    compilation.  Package keys require support from the compiler.  At the moment,
    only GHC 7.10 supports package keys (the reason is that old versions of GHC
    do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
    package database matches with the -package-name embedded in an hi file; so
    the format is fixed.) We fallback to package keys == package IDs for old
    Note: the ./Setup configure fallback script does not try particularly hard to
    pick consistent sets of dependencies.  If your package database is too difficult
    for it to resolve, manually provide installed package IDs or use cabal-install's
    dependency solver.
    Note: This patch *suspends* the reinstall check unless it would result in
    a different package, so cabal-install will now happily reinstall foo-0.1
    compiled against bar-0.2 if foo-0.1 already exists.
    Signed-off-by: Edward Z. Yang <>
Commits on Feb 2, 2014
  1. @23Skidoo

    Remove the BSD3 text from file headers.

    23Skidoo authored
    It's just noise that duplicates information in the 'LICENSE' file.
Commits on May 6, 2013
  1. @23Skidoo

    80-col violation.

    23Skidoo authored
Commits on Mar 18, 2013
  1. @davidlazar

    Add Data and Typeable instances for many types exported by Cabal.

    davidlazar authored
    Note: this adds an orphan Data instance for Data.Version. A fix has been
    proposed upstream.
Commits on Nov 3, 2012
  1. @Peaker

    Use Data.List ( intercalate ) which is exported for more than the las…

    Peaker authored
    …t 3 years instead of reimplementing it all over the place
Commits on Aug 23, 2012
  1. @igfoo
  2. @igfoo

    Add a couple of NFData instances

    igfoo authored
    The Hackage2 server wants them
Commits on Oct 23, 2011
  1. @igfoo

    Rename the cabal directory to Cabal

    igfoo authored
    Makes things a little simpler in GHC's build system if libraries are in
    the same directory as their name.
Something went wrong with that request. Please try again.