This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 15 Jan, 2017 1 commit
  2. 12 Jan, 2017 6 commits
  3. 11 Jan, 2017 4 commits
  4. 08 Jan, 2017 2 commits
  5. 07 Jan, 2017 5 commits
  6. 06 Jan, 2017 6 commits
  7. 05 Jan, 2017 2 commits
  8. 03 Jan, 2017 4 commits
  9. 31 Dec, 2016 3 commits
    • ttuegel's avatar
      Nix: read CABAL_IN_NIX_SHELL · 68d9b17a
      ttuegel authored
      cabal only cares if it is running in a Nix shell that was started by
      another cabal process, so we should not read IN_NIX_SHELL; rather, we
      read a cabal-specific variable for that purpose.
      68d9b17a
    • ttuegel's avatar
      Nix: instantiate expressions in fake Nix shell · a68028ac
      ttuegel authored
      cabal2nix recently changed its generated expressions to read the
      IN_NIX_SHELL environment variable. Now we need to set this variable when
      calling nix-instantiate to produce the same result as calling nix-shell.
      a68028ac
    • Duncan Coutts's avatar
      Refine the fix for requiring Cabal > 1.20 for Setup.hs · 86490508
      Duncan Coutts authored
      Going along with the existing approach of using a constraint rather than
      altering the deps of custom Setup.hs scripts, but make the constraint
      only apply to Cabal instances that are dependencies of Setup.hs scripts
      not all instances of Cabal.
      
      Also rearrange things a little with a dedicated solver policy function
      for adding a min dep on Cabal versions for setup scripts.
      86490508
  10. 30 Dec, 2016 1 commit
  11. 27 Dec, 2016 5 commits
    • Edward Z. Yang's avatar
      Refactor Backpack data structures to be less flexible. · 28af355b
      Edward Z. Yang authored
      
      
      There were a number of fields in 'LinkedComponent' which
      were "too" flexible, in that they were fully determined by
      other fields in the structure.  This refactor deletes those
      fields and replaces them with functions that refer to the
      fields directly.
      
      I also introduce a new type, ComponentInclude, to take
      the place of tuples which were used to represent includes
      (mixins) in Backpack.
      
      There's also more documentation for lots of bits.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      28af355b
    • kristenk's avatar
      Fix build with GHC 7.8.4. · 3d88a3ec
      kristenk authored
      3d88a3ec
    • kristenk's avatar
      Add a test for incremental cycle detection. · 3aee78dd
      kristenk authored
      3aee78dd
    • kristenk's avatar
      Solver: Check for cycles after every step. · f4f57f24
      kristenk authored
      Previously, the solver only checked for cycles after it had already found a
      solution. That reduced the number of times that it performed the check in the
      common case where there were no cycles. However, when there was a cycle, the
      solver could spend a lot of time searching subtrees that already had a cyclic
      dependency and therefore could not lead to a solution. This is part of
      https://github.com/haskell/cabal/issues/3824.
      
      Changes in this commit:
      - Store the reverse dependency map on all choice nodes in the search tree, so
        that 'detectCyclesPhase' can access it at every step.
      - Check for cycles incrementally at every step. Any new cycle must contain the
        current package, so we just check whether the current package is reachable
        from its neighbors.
      - If there is a cycle, we convert the map to a graph and find a strongly
        connected component, as before.
      - Instead of using the whole strongly connected component as the conflict set,
        we select one cycle. Smaller conflict sets are better for backjumping.
      - The incremental cycle detection automatically fixes a bug where the solver
        filtered out the message about cyclic dependencies when it summarized the full
        log. The bug occurred when the failure message was not immediately after the
        line where the solver chose one of the packages involved in the conflict. See
        https://github.com/haskell/cabal/issues/4154.
      
      I tried several approaches and compared performance when solving for
      packages with different numbers of dependencies. Here are the results. None of
      these runs involved any cycles, so they should have only tested the overhead of
      cycle checking. I turned off assertions when building cabal.
      
      Index state: index-state(hackage.haskell.org) = 2016-12-03T17:22:05Z
      GHC 8.0.1
      
      Runtime in seconds:
      Packages                    Search tree depth   Trials   master   This PR   #1      #2
      yesod                       343                 3        2.00     2.00      2.13    2.02
      yesod gi-glib leksah        744                 3        3.21     3.31      4.10    3.48
      phooey                      66                  3        3.48     3.54      3.56    3.57
      Stackage nightly snapshot   6791                1        186      193       357     191
      
      Total memory usage in MB, with '+RTS -s':
      Packages                                        Trials   master    This PR   #1     #2
      yesod                                           1         189       188       188     198
      yesod gi-glib leksah                            1         257       257       263     306
      Stackage nightly snapshot                       1        1288      1338      1432   12699
      
      #1 - Same as master, but with cycle checking (Data.Graph.stronglyConnComp) after
           every step.
      #2 - Store dependencies in Distribution.Compat.Graph in the search tree, and
           check for cycles containing the current package at every step.
      f4f57f24
    • kristenk's avatar
      Remove unnecessary uses of QGoalReason. · dedec725
      kristenk authored
      dedec725
  12. 24 Dec, 2016 1 commit