This project is mirrored from Pull mirroring updated .
  1. 25 Oct, 2016 1 commit
    • Edward Z. Yang's avatar
      Don't use installedPkgs for internal library library dirs. · a1107e21
      Edward Z. Yang authored
      In 1.24, installedPkgs contained only references to the external package
      database, not any internal libraries. In particular, when we built a
      dynamically linked executable, installedPkgs did NOT have a reference to
      the internal library; instead, depLibraryPaths has a special case
      (hasInternalDeps) to add the final libdir to the RPATH.
      In HEAD, after 0d15edef
      , we started adding internal libraries (with the
      INPLACE registrations) to installedPkgs to fix #2971.  But depLibraryPaths
      was not updated, which means that the inplace registrations got picked
      up and added to the RPATH, resulting in bad temporary directories
      showing up in RPATHs.
      In this commit, we just filter out internal entries from installedPkgs
      and compute the library dirs for them from scratch (this code already
      existed, so no loss!)
      Fixes #4025.
      Signed-off-by: default avatarEdward Z. Yang <>
  2. 24 Oct, 2016 1 commit
  3. 23 Oct, 2016 1 commit
    • Erik de Castro Lopo's avatar
      Fix CPP usage · d916298f
      Erik de Castro Lopo authored
      The code had a mixtire of `#ifdef mingw32_HOST_OS` and `#if`. The later
      works but is not really correct. GHC HEAD has just got a new warning flag
      `-Wcpp-undef` which will warn on `#if` used with an undefined identifier.
      Since we want to turn that on in the GHC build system we need to fix cabal
  4. 21 Oct, 2016 3 commits
  5. 20 Oct, 2016 3 commits
    • Edward Z. Yang's avatar
      Only consider dependencies in closure when computing -I on hsc2hs · b736896a
      Edward Z. Yang authored
      Previously, we unconditionally blasted in all packages, even
      if our component didn't actually depend on them.
      This fixes #2971.
      Also, added a test T2971a which is the opposite problem; previously
      we didn't bring in include-dirs from internal libraries.  That
      was fixed by the previous commit.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
    • Christiaan Baaij's avatar
      Add `--dynlibdir` · d2da6558
      Christiaan Baaij authored
      `--dynlibdir` indicates the directory in which dynamic libraries
      are installed. By default this setting is equal to:
      The static libraries will still end up in:
      With `$libsubdir/$abi` as the default directory for dynamic
      libraries, dynamic libraries will by default end up in a
      single shared directory (per package database). This has the
      potential to reduce start-up times for dynamically linked
      executable as only one RPATH per package database will be
      This commit uses the functionality defined in
      to tell GHC's > 8.0.1 package database that dynamic libraries
      are copied to the directories mentioned in the
  6. 19 Oct, 2016 3 commits
  7. 18 Oct, 2016 13 commits
  8. 17 Oct, 2016 2 commits
  9. 16 Oct, 2016 3 commits
    • Duncan Coutts's avatar
      The .ghc.env fix in ghc went in at the end of August · a0881199
      Duncan Coutts authored
      Change the minimum version we use to decide if ghc supports .ghc.env
      files. Previously we declared that it required 8.0.2, but 8.0.2 is not
      out yet so this makes things hard to test.
      It was fixed in the 8.0.x branch at the end of August, so if ghc
      declares itself to be 8.0.1.$date from September or later, then it's ok.
    • Duncan Coutts's avatar
      Make sure ghc ignores any .ghc.environment files · ea1a2cd8
      Duncan Coutts authored
      When we invoke ghc in Cabal it's impostant that we control the
      environment. It's already the case that ghc ignores the .ghc.env files
      when we use -hide-all-packages, but there were a few places where we
      were not using this.
    • Duncan Coutts's avatar
      Add library support for writing ghc environment files · 8fd5ac5c
      Duncan Coutts authored
      This new ghc feature was actually added in ghc 7.10 but very limited,
      then extended significantly in 8.0.1 but with a severe bug for our use
      case and then should be working fine in 8.0.2 onwards.
      This patch adds basic support for writing .ghc.environment files. This
      feature will be used later in cabal-install, but it makes sense for the
      functionality to live in Cabal next to the other code that knows all
      too much about GHC.
      .ghc.environment file support works in ghc 8.0.2 onwards
      It was actually added in ghc 7.10 but very limited, then extended
      significantly in 8.0.1 but with a severe bug for our use case and
      then should be working fine in 8.0.2 onwards.
  10. 14 Oct, 2016 2 commits
  11. 12 Oct, 2016 4 commits
  12. 11 Oct, 2016 3 commits
  13. 08 Oct, 2016 1 commit