This project is mirrored from Pull mirroring updated .
  1. 12 Dec, 2014 1 commit
  2. 03 Dec, 2014 1 commit
  3. 26 Nov, 2014 1 commit
    • Edward Z. Yang's avatar
      Preliminary support for compiling signature files, using --instantiate-with. · 0ef39071
      Edward Z. Yang 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: default avatarEdward Z. Yang <>
  4. 18 Nov, 2014 1 commit
    • Luite Stegeman's avatar
      add data-dir to InstalledPackageInfo · 7fa8f884
      Luite Stegeman authored
      the datadir location for the inplace InstallDirs was pointing to the top directory
      of the package instead of the directory containing the data. this has been fixed.
      since templates have already been expanded at this point, datasubdir raises an
      exception an cannot be used in generalInstalledPackageInfo. therefore the
      full path is stored in datadir.
  5. 04 Nov, 2014 1 commit
    • Edward Z. Yang's avatar
      Consolidate exposed-modules and reexported-modules in InstalledPackageInfo. · 1f8a0a20
      Edward Z. Yang authored
      A note first: this patch does NOT modify the user-facing experience in Cabal
      files; it only changes how we register information in the installed package
      This patch takes the exposed-modules and reexported-modules fields in
      the InstalledPackageInfo structure and consolidates them into just the
      exposed module fields, which now has a Maybe flag indicating if a
      module is reexported and, if it is, what the original module was.  I've
      also added in a field for signatures although it is currently unused.
      The big benefit of this change is that it will make processing at the GHC level
      much more uniform when we add signatures: signatures can also be reexported
      and the new representation means we can share the code.
      Signed-off-by: default avatarEdward Z. Yang <>
  6. 19 Oct, 2014 1 commit
  7. 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.
  8. 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
  9. 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 <>
  10. 12 May, 2014 1 commit
  11. 14 Apr, 2014 1 commit
  12. 02 Feb, 2014 1 commit
  13. 03 Oct, 2013 1 commit
  14. 19 Apr, 2013 1 commit
  15. 20 Mar, 2013 1 commit
  16. 15 Mar, 2013 1 commit
  17. 12 Mar, 2013 1 commit
  18. 26 Nov, 2012 1 commit
  19. 22 Aug, 2012 1 commit
  20. 11 Aug, 2012 1 commit
  21. 24 Jun, 2012 2 commits
  22. 23 Oct, 2011 1 commit
  23. 18 Oct, 2011 1 commit
  24. 08 Aug, 2011 1 commit
  25. 19 Jun, 2011 1 commit
  26. 17 Jun, 2011 1 commit
  27. 31 Jan, 2011 1 commit
  28. 17 Jan, 2011 1 commit
  29. 18 Dec, 2010 1 commit
  30. 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.
  31. 30 Mar, 2010 1 commit
  32. 28 Dec, 2009 1 commit
  33. 11 Dec, 2009 1 commit
  34. 29 Nov, 2009 1 commit
  35. 28 Nov, 2009 1 commit
  36. 05 Oct, 2009 1 commit
  37. 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
  38. 22 Aug, 2009 1 commit