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
      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 <>
  3. 17 Jul, 2014 1 commit
  4. 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 <>
  5. 24 Jun, 2014 1 commit
  6. 09 Feb, 2014 1 commit
  7. 05 Feb, 2014 1 commit
    • Duncan Coutts's avatar
      Put quotes around program names in some error messages · e1052c3e
      Duncan Coutts authored
      One user reported being rather confused by the message:
        cabal: The program happy version >=1.18.5 is required but it could
        not be found.
      I guess they must have been wondering what a happy version was. They
      said that this is much clearer:
        cabal: The program 'happy' version >=1.18.5 is required but it could
        not be found.
      So that's what we now do.
  8. 02 Feb, 2014 1 commit
  9. 19 Dec, 2013 1 commit
  10. 06 Dec, 2013 3 commits
  11. 05 Dec, 2013 2 commits
  12. 25 Oct, 2013 2 commits
    • Duncan Coutts's avatar
      Rearange and simplify the --dependency configure code a bit · 6002f623
      Duncan Coutts authored
      Use a map from package name rather than from constraint, for the
      info on the specific packages to use.
    • idontgetoutmuch's avatar
      Add an explicit way of specifying dependencies on the command line · caba878e
      idontgetoutmuch authored
      If the package names do not match
      then this gives an error
      Setup.hs: The following names do match their hash name:
      (foo, MyOtherLib)
      If the hash is incorrect e.g.
      then this gives an error
      Setup.hs: The following dependencies do not exist:
  13. 07 Oct, 2013 1 commit
  14. 03 Oct, 2013 1 commit
  15. 29 Aug, 2013 1 commit
  16. 25 Aug, 2013 1 commit
  17. 23 Aug, 2013 1 commit
    • Mikhail Glushenkov's avatar
      Backwards compatibility patch for cross-compilation changes. · b57b1158
      Mikhail Glushenkov authored
      Changes back the types of 'configCompiler' and 'configCompilerEx', but marks
      them as deprecated. Adds new functions 'configCompilerEx' and
      The remaining functions that changed type after the cross-compilation changes
      shouldn't matter from the backwards compatibility standpoint:
          * InstallDirs.{absoluteInstallDirs, prefixRelativeInstallDirs,
            initialPathTemplateEnv} - the versions in D.S.LocalBuildInfo retain their
            old types and are usually used instead. In any case, removing the Platform
            parameter from here is problematic because the default install dirs now
            include $arch and $os vars.
          * D.S.Configure.configure - shouldn't be used by the setup scripts.
      See #1214 for the original (backwards-incompatible) patches.
  18. 19 Aug, 2013 2 commits
  19. 10 Aug, 2013 1 commit
    • Duncan Coutts's avatar
      Add a configure --extra-prog-path flag · 046c0866
      Duncan Coutts authored
      Can be used to add extra dirs to the end of the program search path.
      This in mainly useful as a config file entry rather than a command line
      flag, but it'll exists as both.
  20. 03 Aug, 2013 1 commit
  21. 17 Jul, 2013 1 commit
  22. 14 May, 2013 1 commit
  23. 26 Apr, 2013 1 commit
  24. 25 Apr, 2013 1 commit
  25. 24 Apr, 2013 2 commits
  26. 22 Apr, 2013 1 commit
  27. 20 Mar, 2013 1 commit
  28. 12 Mar, 2013 1 commit
  29. 01 Mar, 2013 1 commit
    • lukexi's avatar
      Return Maybe Platform as part of compiler configure, and place it in... · 7a0941c8
      lukexi authored
      Return Maybe Platform as part of compiler configure, and place it in LocalBuildInfo as hostPlatform.
      GHC infers the platform form ghc --info using new 'platformFromTriple' function. Other compilers return Nothing, which triggers fallback to old behavior of using buildPlatform. hostPlatform is then threaded through to initialPathTemplateEnv.
  30. 28 Feb, 2013 1 commit
  31. 10 Dec, 2012 1 commit
  32. 26 Nov, 2012 2 commits