This project is mirrored from Pull mirroring updated .
  1. 03 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Switch InstallPlan over to using IPID-indexed PackageIndex. · ff6c718b
      Edward Z. Yang authored
      While this doesn't let us get rid of Distribution.Client.PackageIndex,
      it does make InstallPlan more flexible, so we can have the same
      package name-package version in the install plan multiple times.
      We do this by synthesizing fake installed package IDs to act
      as placeholders prior to compilation.
      There is some shindig with 'FakeMap' in PackageIndex, check out
      the Note in that file for more details.
      This reverts commit a5a0f8e1959003ee702c04a23375a60d48f03f90, with
      a bugfix for linearizeInstallPlan.
      Fixes #2123
  2. 27 Sep, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Re-allow `configure-option` in config file (re #2122) · 07030ef3
      Herbert Valerio Riedel authored
      A couple of settings were filtered out since
      74cb2909 including
      `configure-option`. However, it turns out you may want to
      persist some options to `configure`, such as e.g.
      when working in a Cygwin host environment, but using a Mingw
      toolchain (such as the one bundled with the Windows GHC bindist).
      Approved by @dcoutts
  3. 26 Sep, 2014 2 commits
  4. 25 Sep, 2014 2 commits
  5. 24 Sep, 2014 1 commit
  6. 23 Sep, 2014 1 commit
  7. 22 Sep, 2014 1 commit
    • Edward Z. Yang's avatar
      Fix three bugs with fake-map implementation for PackageIndex. · f59bab10
      Edward Z. Yang authored
      1. When we union PackageIndexes together, prefer the later one.
         This idiom is used when we update the processing-state of
         packages in an InstallPlan.
      2. dependencyInconsistencies' was missing a number of indirections
         through the fakeMap, so in some cases we incorrectly concluded
         packages were not equal when they were.
      3. We need to initialize the fakeMap with any pre-installed packages,
         otherwise the invariant check for configured-packages will fail.
      Signed-off-by: default avatarEdward Z. Yang <>
  8. 18 Sep, 2014 2 commits
  9. 10 Sep, 2014 1 commit
  10. 27 Aug, 2014 2 commits
  11. 24 Aug, 2014 1 commit
  12. 22 Aug, 2014 2 commits
  13. 19 Aug, 2014 2 commits
  14. 18 Aug, 2014 2 commits
  15. 13 Aug, 2014 2 commits
  16. 04 Aug, 2014 3 commits
    • Edward Z. Yang's avatar
      Disable reinstalls with distinct package keys for now. · d3a696a3
      Edward Z. Yang authored
      Duncan requested that cabal-install not try to put multiple entries in the
      package database with duplicate package IDs (foo-0.1) until other tools (in
      particular GHC) are able to deal with situation in a better way.  We want to
      revert this commit soon, since with this turned on, we basically don't get any
      benefit from the package key refactoring (no deliverance from Cabal hell.)
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Add $pkgkey template variable, and use it for install paths. · 1d33c8f5
      Edward Z. Yang authored
      At the moment, $pkgkey is not supported for build reports, although in
      principle we could add support for it, assuming that the configure step
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Implement package keys, distinguishing packages built with different deps/flags · 41610a0b
      Edward Z. Yang 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: default avatarEdward Z. Yang <>
  17. 02 Aug, 2014 2 commits
  18. 29 Jul, 2014 3 commits
  19. 27 Jul, 2014 4 commits
  20. 25 Jul, 2014 2 commits
  21. 21 Jul, 2014 1 commit
    • Isamu Mogi's avatar
      Read installed package info file as UTF-8 · 44a261d4
      Isamu Mogi authored
      Currently installed package info file is written in UTF-8. So UTF-8
      should be used explicitly or it can cause "invalid byte sequence"
      error if system encoding is incompatible to UTF-8.
  22. 17 Jul, 2014 2 commits