This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 04 Dec, 2014 1 commit
  2. 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
  3. 19 Oct, 2014 2 commits
  4. 19 Aug, 2014 1 commit
  5. 18 Aug, 2014 1 commit
  6. 29 Jul, 2014 1 commit
  7. 27 Jul, 2014 1 commit
  8. 28 Jun, 2014 1 commit
  9. 23 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · f950e8d7
      Andres Löh authored
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      
      (cherry picked from commit 3dcddea4)
      
      Conflicts:
      	cabal-install/Distribution/Client/Dependency.hs
      f950e8d7
  10. 19 May, 2014 2 commits
    • Andres Löh's avatar
      Configurable strong/weak flags. · 3dcddea4
      Andres Löh authored
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      3dcddea4
    • Mikhail Glushenkov's avatar
      Increase defaultMaxBackjumps to 2000 (from 200). · 0229cd52
      Mikhail Glushenkov authored
      As suggested by Anders Löh in #1780.
      
      (cherry picked from commit e2b481a0)
      0229cd52
  11. 14 May, 2014 1 commit
  12. 22 Apr, 2014 2 commits
  13. 20 Apr, 2014 1 commit
  14. 18 Apr, 2014 2 commits
  15. 17 Apr, 2014 3 commits
  16. 12 Apr, 2014 3 commits
  17. 02 Apr, 2014 1 commit
    • Ian D. Bollinger's avatar
      Fix #1569. · 85fecab0
      Ian D. Bollinger authored
      * Change `guessPackageName` to translate arbitrary strings into valid
      package names.
      * Change type of `packageName` flag from String to PackageName and
      reject names that do not pass PackageName's corresponding parse
      function.
      85fecab0
  18. 21 Mar, 2014 1 commit
  19. 05 Mar, 2014 2 commits
  20. 03 Mar, 2014 1 commit
  21. 21 Dec, 2013 1 commit
  22. 19 Dec, 2013 3 commits
  23. 17 Dec, 2013 1 commit
  24. 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
  25. 06 Dec, 2013 2 commits
  26. 05 Dec, 2013 3 commits