This project is mirrored from Pull mirroring updated .
  1. 27 Aug, 2014 1 commit
    • Duncan Coutts's avatar
      Change rep of module re-exports, and do resolution ourselves · a3d3273a
      Duncan Coutts 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.
  2. 04 Aug, 2014 2 commits
    • 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
  3. 16 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Implement "reexported-modules" field, towards fixing GHC bug #8407. · 62450f9a
      Edward Z. Yang authored
      Re-exported modules allow packages to reexport modules from their
      dependencies without having to create stub files.  Reexports of the same
      original module don't count as ambiguous imports when module finding
      occurs.  The syntax is:
          "orig-pkg" OrigName as NewName
      You can omit 'as NewName', in which case it is reexported as the same
      name.  Self referential aliases work too; however, they're only visible
      to packages which depend on this package.
      Left to future work: just provide a module name 'OrigName', where ghc-pkg
      figures out what the source package is.
      Signed-off-by: default avatarEdward Z. Yang <>
  4. 14 Apr, 2014 1 commit
  5. 02 Feb, 2014 1 commit
  6. 03 Oct, 2013 1 commit
  7. 19 Apr, 2013 1 commit
  8. 20 Mar, 2013 1 commit
  9. 15 Mar, 2013 1 commit
  10. 12 Mar, 2013 1 commit
  11. 26 Nov, 2012 1 commit
  12. 22 Aug, 2012 1 commit
  13. 11 Aug, 2012 1 commit
  14. 24 Jun, 2012 2 commits
  15. 23 Oct, 2011 1 commit
  16. 18 Oct, 2011 1 commit
  17. 08 Aug, 2011 1 commit
  18. 19 Jun, 2011 1 commit
  19. 17 Jun, 2011 1 commit
  20. 31 Jan, 2011 1 commit
  21. 17 Jan, 2011 1 commit
  22. 18 Dec, 2010 1 commit
  23. 15 May, 2010 1 commit
    • Duncan Coutts's avatar
      Fix register --global/--user · 993487d7
      Duncan Coutts authored
      It is a rather silly feature and is not guaranteed to work. Having
      configured and built using one set of dbs, there's no guarantee you
      can register into another set. We should probably just remove it.
  24. 30 Mar, 2010 1 commit
  25. 28 Dec, 2009 1 commit
  26. 11 Dec, 2009 1 commit
  27. 29 Nov, 2009 1 commit
  28. 28 Nov, 2009 1 commit
  29. 05 Oct, 2009 1 commit
  30. 26 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Add the ABI hash to the InstalledPackageId for inplace registrations too · 018ec60f
      Simon Marlow authored
      Previously, we just added a -inplace suffix, but this will cause
      problems when developing multiple packages inplace, and then
      installing them.
      Also, there was a round of refactoring: registerPackage now takes the
      InstalledPackageId as an argument, and generateRegistrationInfo is
      exposed for constructing it.  This means that callers of
      registerPackage get to munge the InstalledPackageInfo before it is
  31. 22 Aug, 2009 2 commits
  32. 06 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Add a unuque identifier for installed packages (part 9 of 9) · f76e38cb
      Simon Marlow authored
      When registering, choose the InstalledPackageId.
       - When registering inplace, use "foo-1.0-inplace"
       - If this isn't GHC, just use "foo-1.0-installed"
       - When installing a package with GHC, call
         Distribution.Simple.GHC.libAbiHash to get the hash, and
         use "foo-1.0-<hash>".
  33. 10 Jul, 2009 1 commit
  34. 05 Jul, 2009 1 commit
  35. 07 Jun, 2009 1 commit
    • Duncan Coutts's avatar
      Rewrite the Register module · 02ac5ebf
      Duncan Coutts authored
      It was getting increasingly convoluted and incomprehensible.
      Now uses the Program.HcPkg and Program.Scripts modules.
  36. 05 Jun, 2009 1 commit
  37. 31 May, 2009 1 commit