This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 27 Aug, 2014 2 commits
    • 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.
      a3d3273a
    • Duncan Coutts's avatar
      20e35704
  2. 22 Aug, 2014 1 commit
  3. 20 Aug, 2014 1 commit
  4. 15 Aug, 2014 1 commit
  5. 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 <ezyang@cs.stanford.edu>
      2b50d0a7
    • 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
      succeeds.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      1d33c8f5
    • 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
      database.
      
      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
      versions.
      
      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 <ezyang@cs.stanford.edu>
      41610a0b
    • Edward Z. Yang's avatar
    • kgardas's avatar
      9326c359
  6. 01 Aug, 2014 1 commit
  7. 27 Jul, 2014 3 commits
  8. 23 Jul, 2014 1 commit
    • ttuegel's avatar
      D.Compat.CreatePipe: use locale encoding · 93918b1b
      ttuegel authored
      Issue #1895. `createPipe` opened handles in binary mode by default,
      which mangles text encoded for the current locale. Now, `hSetEncoding`
      is called on the new handles. This requires `base >= 4.2`.
      93918b1b
  9. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Weaken dependency on process. · ebd4d4b9
      Edward Z. Yang authored
      
      
      GHC 7.6 still distributes by default with an old version of process, which
      means that requiring the most recent version prevents GHC from properly
      bootstrapping out of the box.  In this patch, we relax the version requirement
      on process, disabling proper ctl-c handling when the version is not sufficiently
      new.
      
      Perhaps one problem with lowering the bound, is if someone attempts to install
      Cabal out of the box on GHC 7.6, the dependency solver will prefer the old
      installed version, so it is very easy to end up with a cabal-install which
      doesn't have working ctl-c.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      ebd4d4b9
  10. 20 Jul, 2014 1 commit
  11. 17 Jul, 2014 4 commits
  12. 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 <ezyang@cs.stanford.edu>
      62450f9a
  13. 02 Jul, 2014 1 commit
  14. 28 Jun, 2014 2 commits
  15. 26 Jun, 2014 1 commit
  16. 24 Jun, 2014 1 commit
  17. 16 Jun, 2014 1 commit
  18. 12 Jun, 2014 1 commit
  19. 20 May, 2014 2 commits
    • ttuegel's avatar
      Always stream test output concurrently · e7236056
      ttuegel authored
      Issue #1810. Some test suites would freeze if invoked with
      `--show-details=always` instead of `--show-details=streaming` because
      output would build up in the pipe without being cleared. This corrects
      the issue by forcing the length of the output string in another thread.
      
      (cherry picked from commit e5a07013)
      e7236056
    • ttuegel's avatar
      Always stream test output concurrently · e5a07013
      ttuegel authored
      Issue #1810. Some test suites would freeze if invoked with
      `--show-details=always` instead of `--show-details=streaming` because
      output would build up in the pipe without being cleared. This corrects
      the issue by forcing the length of the output string in another thread.
      e5a07013
  20. 15 May, 2014 1 commit
  21. 14 May, 2014 1 commit
    • Thomas M. DuBuisson's avatar
      Re-order CC options. · 9d7a8ff9
      Thomas M. DuBuisson authored
      A default -O2 coming second over-rides packages that specify -O3.
      Among other issues, this means expected AVX instructions are not being
      generated and performance takes orders of magnitude dive in some cases.
      9d7a8ff9
  22. 12 May, 2014 1 commit
  23. 10 May, 2014 4 commits
    • Iain Nicol's avatar
      Fix: "cabal haddock" uses CPP overzealously · ba4ae3d0
      Iain Nicol authored
      Until recently we supported ancient versions of Haddock, pre v2.0.  To
      support the CPP extension with such versions, cabal had to invoke the
      CPP before invoking Haddock on the output.  For simplicity cabal would
      invoke the CPP on all Haskell files, if any Haskell file required CPP.
      However, invoking CPP on a file which does not require it can cause
      build failures.
      
      Haddock v2.0+ supports the CPP via GHC, and even automatically
      preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
      simply need only tell Haddock to enable the CPP when the CPP is a
      package level default extension.
      
      Fixes issue #1808.
      ba4ae3d0
    • Iain Nicol's avatar
      Use Haddock's builtin support for .lhs and CPP · 5729bc5c
      Iain Nicol authored
      This is a code simplification on our end.
      
      Thanks to Mikhail Glushenkov for the suggestion.
      5729bc5c
    • Iain Nicol's avatar
      Remove support for Haddock versions < 2.0 · 98c537f1
      Iain Nicol authored
      Dropping this support is unlikely to be a problem in practice.  Debian
      oldstable is currently on version 2.6.0 of Haddock, for example.
      
      This change enables future code simplification.  Currently we
      preprocess both Haskell files requiring the CPP and Literate Haskell
      files; newer versions of Haddock can handle these natively.
      
      Fixes issue #1718.
      98c537f1
    • Iain Nicol's avatar
      a718eb07
  24. 24 Apr, 2014 2 commits