This project is mirrored from Pull mirroring updated .
  1. 22 Sep, 2014 2 commits
  2. 18 Sep, 2014 1 commit
  3. 15 Sep, 2014 1 commit
  4. 14 Sep, 2014 6 commits
  5. 10 Sep, 2014 1 commit
  6. 30 Aug, 2014 3 commits
  7. 29 Aug, 2014 1 commit
  8. 28 Aug, 2014 3 commits
  9. 27 Aug, 2014 6 commits
  10. 25 Aug, 2014 1 commit
    • Mikhail Glushenkov's avatar
      Bump version. · 7a24dd6a
      Mikhail Glushenkov authored
      So that the 'install_from_tarball' build bot step doesn't try to use the old
      1.21 snapshot that comes with GHC HEAD.
  11. 22 Aug, 2014 1 commit
  12. 20 Aug, 2014 1 commit
  13. 15 Aug, 2014 1 commit
  14. 08 Aug, 2014 1 commit
  15. 04 Aug, 2014 5 commits
    • Edward Z. Yang's avatar
      Fix regression for V09 test library handling. · 2b50d0a7
      Edward Z. Yang authored
      detailed-1.0 test libraries allow users to define a test library as part
      of package, which has a different package ID than the original library.
      When I made the change to packageKey, I forgot to assign new package keys
      here; the result was that the test library was compiled with the same
      package key as the original.  The fix is a bit of a hack, since arguably
      this should have been done properly in the configure step!
      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 <>
    • Edward Z. Yang's avatar
    • kgardas's avatar
  16. 01 Aug, 2014 1 commit
  17. 27 Jul, 2014 5 commits