This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Mar, 2015 1 commit
  2. 04 Mar, 2015 1 commit
  3. 03 Mar, 2015 3 commits
  4. 19 Jan, 2015 2 commits
  5. 18 Jan, 2015 3 commits
  6. 12 Jan, 2015 1 commit
  7. 09 Jan, 2015 4 commits
  8. 04 Jan, 2015 3 commits
  9. 03 Jan, 2015 1 commit
    • tibbe's avatar
      Add support for emitting debug info · fbf84997
      tibbe authored
      If the compiler (e.g. GHC 7.10) supports outputting OS native debug
      info (e.g. DWARF) passing --enable-debug-info[=n] to cabal will
      instruct it to do so.
      fbf84997
  10. 02 Jan, 2015 1 commit
  11. 31 Dec, 2014 1 commit
  12. 30 Dec, 2014 2 commits
  13. 24 Dec, 2014 1 commit
  14. 23 Dec, 2014 4 commits
  15. 19 Dec, 2014 2 commits
    • Christiaan Baaij's avatar
      Always setup (DY)LD_LIBRARY_PATH for testsuite · 2158e3c9
      Christiaan Baaij authored
      Now that Cabal is in charge of RPATH handling on certain OS',
      we must always setup a correct (DY)LD_LIBRARY_PATH when
      running the testsuite. Not just when we are building relocatable
      packages.
      
      The "problem" is, is that Cabal now adds an RPATH pointing
      to the installation location of the library. However, during
      testing, the library won't be there yet. We much hence setup
      a (DY)LD_LIBRARY_PATH that includes the dist/build dir.
      2158e3c9
    • tibbe's avatar
      a7acd899
  16. 18 Dec, 2014 8 commits
    • barmston's avatar
      cabal install can be used inside a cabal exec environment · 0a4aed40
      barmston authored
      Inside a cabal exec environment cabal should be configured to always use the
      correct environment. When there is a sandbox this is addressed by setting the
      CABAL_SANDBOX_CONFIG environment variable.
      
      However GHC is configured to use the correct package database through setting
      the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
      Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
      order to avoid having a different view of the package databases to GHC.
      
      In the case of a cabal exec environment being loaded for a cabal sandbox, it
      is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
      that GHC uses the same package database as cabal does.
      
      A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
      to. If it does use of GHC through cabal is permitted.
      
      Fixes #1800
      0a4aed40
    • tibbe's avatar
      Bump dependency on Cabal to 1.22.0.0 · 93b2e257
      tibbe authored
      93b2e257
    • tibbe's avatar
      Bump version numbers to 1.22.0.0 · 82d2fe1f
      tibbe authored
      82d2fe1f
    • Herbert Valerio Riedel's avatar
      Add 'binary' to bootstrap packages · baefd55a
      Herbert Valerio Riedel authored
      This needed since Cabal requires `binary == 0.7.*` which is only
      satisfied by GHC 7.8 and later.
      
      With this, bootstrap.sh now should work for (at least) GHC 7.4 and later
      baefd55a
    • Herbert Valerio Riedel's avatar
      ce5e9fbb
    • Andres Löh's avatar
      Improve solver error messages slightly. · eb9dcd4e
      Andres Löh authored
      As a consequence of treating all flag choices as a common goal for
      conflict set computation, error message slicing was broken and did
      not contain any information about flag choices anymore.
      
      With this change, information about flag choices is once again
      included in error messages.
      eb9dcd4e
    • Andres Löh's avatar
      Fix handling of manual flags. · ca4f58d8
      Andres Löh authored
      This hopefully addresses issue #2280.
      
      The problem was as follows: In the modular solver, manual flags are
      enforced. However, in order to respect manual choices by the user,
      which are still allowed, we would first check if one of the two choices
      had already been disabled, and only if that's not the case, disable
      the non-default choice.
      
      However, a manual user constraint is not the only reason why the default
      flag choice can be disabled at this point. It can already be disabled
      in the validation phase, if it's immediately obvious to the solver at
      this point that it can never work. In such a situation (which is
      described in #2280), the solver would then fail to respect a manual
      flag and allow to change it without user intervention.
      
      The fix seems simple: we now explicitly check whether the flag choice
      has been disabled *by the user*, and only then leave it alone.
      Otherwise, we enforce the manual flag.
      ca4f58d8
    • Luite Stegeman's avatar
      f5e713d7
  17. 16 Dec, 2014 2 commits