This project is mirrored from Pull mirroring updated .
  1. 06 Mar, 2015 1 commit
  2. 04 Mar, 2015 1 commit
  3. 03 Mar, 2015 2 commits
  4. 18 Jan, 2015 3 commits
  5. 09 Jan, 2015 3 commits
  6. 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.
  7. 23 Dec, 2014 3 commits
  8. 19 Dec, 2014 1 commit
    • 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
      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.
  9. 18 Dec, 2014 4 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
    • 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.
    • 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.
    • Luite Stegeman's avatar
  10. 15 Dec, 2014 1 commit
  11. 12 Dec, 2014 9 commits
  12. 10 Dec, 2014 1 commit
    • Luite Stegeman's avatar
      use CompilerInfo rather than CompilerId for resolving flags and · 7d91b773
      Luite Stegeman authored
      path templates.
      CompilerInfo contains more information about the compiler than
      CompilerId, which just stores the flavour and version. In particular,
      CompilerInfo knows an AbiTag, which can be used to tell binary
      incompatible results from the same compiler apart, and detailed
      information about supported languages and extensions.
      Some fields in CompilerInfo may be left unknown (Nothing). This can
      be used in the future to allow partially resolving configurations
      based on supported languages or extensions.
  13. 07 Dec, 2014 6 commits
  14. 04 Dec, 2014 1 commit
  15. 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 <>
  16. 18 Nov, 2014 1 commit
  17. 16 Nov, 2014 1 commit