This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 19 Aug, 2014 1 commit
  2. 18 Aug, 2014 1 commit
  3. 29 Jul, 2014 1 commit
  4. 27 Jul, 2014 1 commit
  5. 28 Jun, 2014 1 commit
  6. 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
  7. 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
  8. 14 May, 2014 1 commit
  9. 22 Apr, 2014 2 commits
  10. 20 Apr, 2014 1 commit
  11. 18 Apr, 2014 2 commits
  12. 17 Apr, 2014 3 commits
  13. 12 Apr, 2014 3 commits
  14. 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
  15. 21 Mar, 2014 1 commit
  16. 05 Mar, 2014 2 commits
  17. 03 Mar, 2014 1 commit
  18. 21 Dec, 2013 1 commit
  19. 19 Dec, 2013 3 commits
  20. 17 Dec, 2013 1 commit
  21. 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
  22. 06 Dec, 2013 2 commits
  23. 05 Dec, 2013 5 commits
  24. 01 Dec, 2013 1 commit
  25. 31 Oct, 2013 1 commit