This project is mirrored from Pull mirroring updated .
  1. 16 Dec, 2015 1 commit
    • Duncan Coutts's avatar
      Extend HcPkg.init support for dir-style package dbs · 12b222af
      Duncan Coutts authored
      The HcPkgInfo useSingleFileDb is split into two: supportsDirDbs and
      requiresDirDbs. Then rather than HcPkg.init callers having to do the
      writeFile [] thing, HcPkg.init does it itself automatically based on the
      HcPkgInfo. In the case that supportsDirDbs is True but requiresDirDbs is
      False then we have a choice, to use dir style or file style. For
      compatability reasons, when using ghc/ghc-pkg for the inplace package db
      we want to use the old file style, even though dir style is supported.
      However in other circumstances (e.g. in places in cabal-install) we
      would like to use the dir style if it's supported, and there are no
      backwards compat issues. So HcPkg.init gains a new Bool arg to request
      using the file style if it's still supported. Only this mode is used
      within Cabal itself, but the non-compat mode is available for other
      The compiler-independent initPackageDB is left with the same old
      behaviour, but a new createPackageDB has the extra compat argument
      (which is only passed to hc-pkg for ghc-pkg).
  2. 09 Oct, 2015 1 commit
    • 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
      This patch replaces InstalledPackageId and PackageKey with a
      new identifier called ComponentId, which has the following
          - 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
          - 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 <>
  3. 17 Aug, 2015 1 commit
  4. 16 Aug, 2015 1 commit
  5. 27 Jan, 2015 1 commit
  6. 18 Dec, 2014 1 commit
  7. 12 Dec, 2014 3 commits
  8. 08 Nov, 2014 1 commit
  9. 12 May, 2014 1 commit
  10. 24 Jul, 2013 1 commit
  11. 19 Apr, 2013 1 commit
  12. 17 Aug, 2012 1 commit
  13. 11 May, 2012 1 commit
    • pcapriotti's avatar
      Adapt to change in GHC package db flags. · 9e030da8
      pcapriotti authored
      GHC and ghc-pkg package db flags changed from '*-package-conf' to
      '*-package-db' in 7.5.  This commit follows the change and introduces a
      version check whenever those flags are used.
  14. 23 Oct, 2011 1 commit
  15. 19 Jun, 2011 1 commit
  16. 25 May, 2011 1 commit
  17. 10 Feb, 2011 2 commits
  18. 16 Aug, 2010 1 commit
  19. 21 May, 2010 1 commit
  20. 15 May, 2010 1 commit
  21. 11 Dec, 2009 1 commit
  22. 02 Dec, 2009 1 commit
  23. 29 Nov, 2009 1 commit
  24. 22 Aug, 2009 1 commit
  25. 06 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Add a unuque identifier for installed packages (part 2 of 9) · fb685e8c
      Simon Marlow authored
      Note: this patch doesn't build on its own, you also need the rest of
      the patch series.
      Compatibility with older GHCs.  When reading a package database
      created by an older version of GHC without installedPackageIds, we
      have to fake an InstalledPackageId for the internal
      So, when reading in an InstalledPackageInfo from an older GHC, we set
      the installedPackageId to be the textual representation of the
      PackageIdentifier: i.e. <package>-<version>.  Now, previously the
      depends field of InstalledPackageInfo was [PackageIdentifier], and is
      now [InstalledPackageId], so we will read each PackageIdentifier as an
      InstalledPackageId (a String).  The dependencies will still point to
      the correct package, however, because we have chosen the
      installedPackageId to be the textual representation of the
  26. 07 Jun, 2009 2 commits