This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 11 Mar, 2015 1 commit
  2. 03 Mar, 2015 1 commit
  3. 09 Jan, 2015 1 commit
  4. 04 Jan, 2015 1 commit
  5. 19 Dec, 2014 1 commit
  6. 18 Dec, 2014 2 commits
  7. 16 Dec, 2014 2 commits
  8. 24 Oct, 2014 1 commit
  9. 20 Oct, 2014 1 commit
    • Erik de Castro Lopo's avatar
      cabal-install : Add a 'user-config' command. · 6d530dd4
      Erik de Castro Lopo authored
      The 'user-config' command allows pseudo-diff-ing and updating of the
      user's ~/.cabal/config file. The diff is against what cabal would
      generated if the user config file did not exist and the update
      command overlays the user's existing settings over the current
      version of the default settings and writes it back to ~/.cabal/config.
      
      Closes: #2159
      6d530dd4
  10. 17 Sep, 2014 1 commit
  11. 10 Sep, 2014 1 commit
  12. 27 Aug, 2014 1 commit
  13. 26 Aug, 2014 1 commit
  14. 25 Aug, 2014 1 commit
    • Mikhail Glushenkov's avatar
      Bump version. · 7a24dd6a
      Mikhail Glushenkov authored
      So that the 'install_from_tarball' build bot step doesn't try to use the old
      1.21 snapshot that comes with GHC HEAD.
      7a24dd6a
  15. 24 Aug, 2014 1 commit
  16. 28 Jun, 2014 2 commits
  17. 26 Jun, 2014 1 commit
  18. 24 May, 2014 1 commit
  19. 14 May, 2014 1 commit
    • barmston's avatar
      Tests for the freeze command · c2032b67
      barmston authored
      Introduced a new test-suite, package-tests, which is intended for black-box
      testing of the cabal binary.
      
      The `PackageTests` module determines which cabal binary is to be tested and
      runs the tests passing each of them the path to that binary. The binary is the
      first cabal binary found on the path. To test a different binary, adjust the
      PATH environment variable.
      
      The `PackageTests.PackageTester` module contains common routines to execute
      the cabal binary and check its results.
      
      Finally, the `PackageTests.Freeze.Check` command contains some tests for the
      freeze command.
      c2032b67
  20. 03 May, 2014 1 commit
  21. 20 Apr, 2014 1 commit
  22. 18 Apr, 2014 2 commits
  23. 16 Apr, 2014 1 commit
  24. 15 Apr, 2014 5 commits
  25. 14 Apr, 2014 1 commit
  26. 22 Dec, 2013 1 commit
    • Brent Yorgey's avatar
      Compat version of readProcessWithExitCode · e2c7ce0f
      Brent Yorgey authored
      * Add a new module, Distribution.Client.Compat.Process, with a
        function readProcessWithExitCode.  Unlike the one from
        System.Process it always catches "does not exist" errors and turns
        them into ExitFailures.
      
      * Change all calls to readProcessWithExitCode to use the new version.
      
      * Fixes #1613.
      e2c7ce0f
  27. 17 Dec, 2013 1 commit
  28. 08 Dec, 2013 1 commit
    • barmston's avatar
      Top-level `freeze` command freezes dependency versions · c6138e81
      barmston authored
      Add new top-level `freeze` command, which resolves the dependencies to exact
      versions and writes a `constraints` section to `cabal.config`. This causes
      future builds to use the same fully constrained dependencies.
      
      The command takes a number of options related to resolving dependencies,
      namely, `--solver`, `--max-backjumps`, `reorder-goals` and
      `--shadow-installed-packages`. These are used to create an `InstallPlan` in
      much the same way that `install` does so. The `InstallPlan` is converted to a
      list and all `PlanPackage`s are inspected to determine their exact version.
      These versions are then either written to `cabal.config` or to standard output
      depending on the presence of `--dry-run`.
      
      Limitations in resolving dependencies
      -------------------------------------
      
      In order to keep the initial implementation of this new command simpler, a
      number of options are not yet supported.  There should be no great difficulty
      in supporting the options `--flags`, `--enable-{tests,benchmarks}`,
      `--constraint` and `--preference`.  However, the options concerned with
      compilers may prove more difficult.
      
      Different versions of GHC ship with different library versions, the
      constraints that are written currently include all dependencies, including
      `base`. This prevents the constraints, as written, from being used with
      alternate versions of GHC.
      
      There are three solutions to this problem: 1) have the user edit the
      constraints section, 2) exclude certain packages from the list of constraints,
      3) develop a mechanism for per-arch-os-compiler constraining. As neither (2)
      nor (3) have been developed we default to (1).
      
      The lack of a good story for per-compiler constraints has lead to the options
      `--with-compiler`, `--ghc`, `--uhc` et al, not being supported.
      
      Further limitations:
      --------------------
      
       - The `cabal.config` file is completely overwritten. Just the `constraints`
         section should be overwritten.
      c6138e81
  29. 05 Dec, 2013 1 commit
  30. 11 Nov, 2013 1 commit
  31. 27 Oct, 2013 1 commit
  32. 26 Oct, 2013 1 commit