This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Jun, 2018 1 commit
  2. 09 May, 2018 2 commits
    • kristenk's avatar
      Solver: Enforce dependencies on libraries (fixes #779). · 6efb5e23
      kristenk authored
      This commit generalizes the fix for issue #4781
      (e86f8389) by tracking dependencies on
      components instead of dependencies on executables.  That means that the solver
      always checks whether a package contains a library before using it to satisfy a
      build-depends dependency.  If a version of a package doesn't contain a library,
      the solver can try other versions.  Associating each dependency with a component
      also moves towards the design for component-based dependency solving described
      in issue #4087.
      6efb5e23
    • kristenk's avatar
      Add CABAL_DIR environment variable for specifying the cabal directory. · a343dee1
      kristenk authored
      CABAL_DIR can be used to run integration tests independently on Windows,
      since setting HOME doesn't affect the location of the APPDATA directory.
      a343dee1
  3. 08 May, 2018 1 commit
    • quasicomputational's avatar
      Allow ** wildcards in globs. · 5e83ef26
      quasicomputational authored
      These are inspired by a plan described in a comment in #2522, and only
      implement a quite limited form of recursive matching: only a single **
      wildcard is accepted, it must be the final directory, and, if a **
      wildcard is present, the file name must include a wildcard.
      
      Or-patterns are not implemented, for simplicity.
      
      Closes #3178, #2030.
      5e83ef26
  4. 19 Apr, 2018 1 commit
    • lspitzner's avatar
      Fix cabal project caching bug, Fix provenance tracking · 4818eb5c
      lspitzner authored
      - Use (projectConfigPath, distProjectFile "") as key
        for config FileMonitor, instead of ().
      - Provenances were previously not tracked for "local" and
        "freeze" configs.
      - Add verbose printing of relevant config file paths.
      
      Fixes #4662 and probably #5225
      4818eb5c
  5. 16 Apr, 2018 1 commit
    • Samuel Gélineau's avatar
      fix infinite loop in D.Client.TargetSelector · 7ecff6e3
      Samuel Gélineau authored
      The pattern guard was clearly meant as a list-comprehension filter,
      but on a let-bound pattern, it instead caused a circular loop in which
      whether the LHS variables are bound the the RHS values depends on the
      values of the LHS variables.
      
      fixes #5081
      7ecff6e3
  6. 10 Apr, 2018 1 commit
  7. 05 Apr, 2018 1 commit
  8. 28 Mar, 2018 3 commits
  9. 27 Mar, 2018 1 commit
  10. 26 Mar, 2018 1 commit
    • alexbiehl's avatar
      Haddock: Generate haddock for components · 4466310e
      alexbiehl authored
      Currently settings `documentation: true` enables documentation
      generation via haddock for your whole package, including tests and benchmarks.
      However, there are additional flags to control generation of
      documentation for this "second class" documentation targets, which are
      currently not honored at the cabal-install side of things. Namely,
      `tests`, `benchmarks`, `executables`, etc. provided under the
      `haddock` section in your `$CABAL_HOME/config`.
      
      This patch adds a more sensible approach to documentation generation
      via haddock. Also enabling `new-haddock` to generate documentation for
      single components instead whole packages.
      
      The behaviour works like this:
      
          - Setting `documentation: true` or passing
            `--enable-documentation` to cabal-install enable documentation
            for any component in the build plan honoring the respective
            flags for tests, benchmarks, exes, foreignlibs, etc.
      
          - Invoking new-haddock with a target selector will make sure
            the respective flags for "second class" doc targets are set
            correctly. E.g.
      
            $ new-haddock tests
      
            Will generate documentation for the testsuite of your package
            event if you have `tests: false` in your haddock section.
      4466310e
  11. 25 Mar, 2018 1 commit
  12. 22 Mar, 2018 1 commit
  13. 13 Mar, 2018 2 commits
  14. 11 Mar, 2018 3 commits
  15. 10 Mar, 2018 3 commits
  16. 09 Mar, 2018 1 commit
  17. 06 Mar, 2018 3 commits
  18. 05 Mar, 2018 3 commits
  19. 03 Mar, 2018 2 commits
    • Herbert Valerio Riedel's avatar
      Set upper bound on setup.Cabal relative to current version · c92b7150
      Herbert Valerio Riedel authored
      As we can't predict the future, we also place a global upper
      bound on the lib:Cabal version we know how to interact with:
      
      The upper bound is computed by incrementing the current major
      version twice in order to allow for the current version, as
      well as the next adjacent major version (one of which will not
      be released, as only "even major" versions of Cabal are
      released to Hackage or bundled with proper GHC releases).
      
      For instance, if the current version of cabal-install is an odd
      development version, e.g.  Cabal-2.1.0.0, then we impose an
      upper bound `setup.Cabal < 2.3`; if `cabal-install` is on a
      stable/release even version, e.g. Cabal-2.2.1.0, the upper
      bound is `setup.Cabal < 2.4`. This gives us enough flexibility
      when dealing with development snapshots of Cabal and cabal-install.
      
      This addresses #415
      
      (cherry picked from commit e66106c7)
      c92b7150
    • Herbert Valerio Riedel's avatar
      Fine-tune lower bound on lib:Cabal · de880a54
      Herbert Valerio Riedel authored
      GHC 8.4.1-rc1 (GHC 8.4.0.20180224) unfortunately still shipped with a
      devel snapshot of Cabal-2.1.0.0; but GHC 8.4.1 final will ship w/
      lib:Cabal-2.2.0.0
      
      (cherry picked from commit 5066672f)
      de880a54
  20. 26 Feb, 2018 2 commits
  21. 25 Feb, 2018 1 commit
    • kristenk's avatar
      Skip processing the solver log when the log isn't needed. · 9592a392
      kristenk authored
      I tested this change by comparing performance with both
      c01d92f5 (before any refactoring needed to
      implement this change) and 4d28102d (the
      previous commit), using hackage-benchmark.  Since the refactoring changed the
      meaning of the backjump count, I only timed "install" commands that didn't reach
      the backjump limit.  I chose several commands that ran for different amounts of
      time, including the long running example from issue #4976.
      
      Comparing c01d92f5 (cabal1) and this commit (cabal2):
      
      compiler: GHC 8.2.1
      index state: 2018-02-16T02:47:32Z
      extra hackage-benchmark flags:
      --packages="aeson yesod wolf" --pvalue=0.01 --trials=50 --print-skipped-packages
      
      package result1       result2             mean1       mean2     stddev1     stddev2     speedup
      aeson   (not significant)
      yesod   Solution      Solution           2.270s      2.258s      0.027s      0.031s      1.005
      wolf    Solution      Solution           7.337s      7.234s      0.056s      0.047s      1.014
      
      Comparing 4d28102d (cabal1) and this commit (cabal2) with the same environment
      and flags as above:
      
      package result1       result2             mean1       mean2     stddev1     stddev2     speedup
      aeson   (not significant)
      yesod   (not significant)
      wolf    Solution      Solution           7.297s      7.245s      0.045s      0.048s      1.007
      
      hackage-benchmark currently doesn't print the results when they aren't
      significant, so I reran "cabal install --dry-run aeson", and it ran for about
      1.6 seconds and found a solution.
      
      Comparing c01d92f5 (cabal1) and this commit (cabal2) on issue #4976:
      
      compiler: GHC 7.10.3
      extra hackage-benchmark flags:
      --cabal1-flags="--index-state='2017-12-25T17:31:19Z' --enable-tests --max-backjumps=-1"
      --cabal2-flags="--index-state='2017-12-25T17:31:19Z' --enable-tests --max-backjumps=-1"
      --packages=servant-mock --pvalue=0.01 --trials=50 --print-skipped-packages --print-trials
      
      trial/summary    package      result1       result2             mean1       mean2     stddev1     stddev2     speedup
      ...
      summary          servant-mock Solution      Solution          39.693s     38.863s      0.181s      0.174s      1.021
      
      Comparing 4d28102d (cabal1) and this commit (cabal2) on issue #4976 with the
      same environment and flags as above:
      
      trial/summary    package      result1       result2             mean1       mean2     stddev1     stddev2     speedup
      ...
      summary          servant-mock Solution      Solution          39.659s     38.960s      0.195s      0.162s      1.018
      
      Overall, this seems like a very small performance improvement.
      9592a392
  22. 24 Feb, 2018 4 commits
    • Herbert Valerio Riedel's avatar
      Implement ghc/cabal compatiblity matrix (re #415) · 71e797ea
      Herbert Valerio Riedel authored
      This injects lower-bound constraints on Cabal for custom setup
      dependencies to prevent the solver from selecting unsupported
      configurations.
      
      Previously we already added an absolute lower bound `Cabal >= 1.20`
      for nix-local builds, as that's the minimum version we need to be able
      to interact with custom Setup.hs scripts. This refines with logic by
      restricting that lower bound even more based on GHC version.
      
      This patch augments this with the following rules:
      
      - GHC 8.4+   constrains  Cabal >= 2.2
      - GHC 8.2    constrains  Cabal >= 2.0
      - GHC 8.0    constrains  Cabal >= 1.24
      - GHC 7.10   constrains  Cabal >= 1.22
      - (default   constraint  Cabal >= 1.20)
      
      This only affects nix-style local builds codepaths.
      71e797ea
    • kristenk's avatar
      Use RetryLog to avoid an O(N) update to the end of the solver log. · 021c8308
      kristenk authored
      This commit delays converting the solver's log from a RetryLog (See #3674) to a
      Progress as long as possible, until immediately before the call to
      'showMessages', which needs to pattern match on the log messages.  This
      maximizes the number of operations on the end of the log that are done in O(1)
      time instead of O(N) time.
      021c8308
    • kristenk's avatar
      Enforce the backjump limit before creating the solver log. · 6ae39676
      kristenk authored
      Previously, the solver enforced the backjump limit by counting 'Backjump'
      messages during log processing.  This commit instead enforces the backjump limit
      when the solver explores the search tree.  This change simplifies the log
      processing step and allows us to skip creating the log when we don't need to
      print it, though that's not implemented in this commit.
      
      This commit changes the meaning of the backjump count slightly.  Previously the
      solver counted a backjump every time it backtracked and added at least one
      variable to the conflict set.  Now it counts a backjump every time it unions all
      conflict sets at the current level, even if the union is the same as the
      conflict set from the level below.  That means that more steps count as
      backjumps, and the solver can reach the backjump limit slightly earlier.
      
      This commit also changes the log messages.  Previously, the solver sometimes
      omitted the last 'Backjump' message, but this commit always prints a 'Backjump'
      message when the solver fails.  Additionally, the level numbers for some
      'Backjump' messages changed to match the levels where the conflict sets were
      unioned.
      6ae39676
    • kristenk's avatar
  23. 19 Feb, 2018 1 commit