This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
- 05 Jan, 2017 2 commits
-
-
Robert Henderson authored
-
Robert Henderson authored
-
- 03 Jan, 2017 5 commits
-
-
Mikhail Glushenkov authored
[ci skip]
-
Mikhail Glushenkov authored
[ci skip]
-
kristenk authored
Add a comment to 'Distribution.Solver.Modular.Cycles.findCycles'.
-
kristenk authored
[ci skip]
-
A signature package is a package that contains only signatures but no modules (equivalently, it is a package that has no provisions.) Previously, we did not treat signature packages any differently from normal packages, which, in particular, meant that when we instantiated a package using a signature package, we also instantiated the signature package. This is actually pretty useless, because we never actually use the instantiated signature (there's no code that actually gets compiled in this case). This patch treats signature packages specially, so that we don't actually instantiate dependencies on them. This means we have to compile less packages when handling signatures. Good! Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 02 Jan, 2017 1 commit
-
-
ttuegel authored
Nix integration improvements
-
- 01 Jan, 2017 2 commits
-
-
Herbert Valerio Riedel authored
Refine the fix for requiring Cabal > 1.20 for Setup.hs Fixes #4196
-
Herbert Valerio Riedel authored
-
- 31 Dec, 2016 6 commits
-
-
ttuegel authored
Mention that we allow `shell.nix` or `default.nix`, the same as `nix-shell`.
-
ttuegel authored
-
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.
-
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.
-
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.
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 30 Dec, 2016 1 commit
-
-
ttuegel authored
-
- 27 Dec, 2016 5 commits
-
-
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:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
-
-
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.
-
-
- 24 Dec, 2016 2 commits
-
-
Mikhail Glushenkov authored
Fix #3440.
-
Mikhail Glushenkov authored
Fix provided by @mvkorpel.
-
- 22 Dec, 2016 4 commits
-
-
Mikhail Glushenkov authored
[ci skip]
-
Mikhail Glushenkov authored
Mark `template-haskell` non-upgradable (again)
-
Mikhail Glushenkov authored
Depend on echo to fix #4128
-
Ryan Scott authored
-
- 21 Dec, 2016 2 commits
-
-
Herbert Valerio Riedel authored
65e9b88b made template-haskell non-upgradable 65ae95c1 made it upgradable again ...and this commit makes it non-upgradable again While there may be a few cases when `template-haskell` can be reinstalled, it's generally not advisable, and causes more harm than the benefit in the few cases where we'd gain install-plan flexibility (e.g. when only template-haskell's API is needed for compile, but no actual TH evaluation takes place). Closes #4098
-
Edward Z. Yang authored
This reverts commit eca045bc. Revert "Add fingerprint of Generic representation when serializing." This reverts commit ebcae71d.
-
- 20 Dec, 2016 1 commit
-
-
Herbert Valerio Riedel authored
cabal-version semantics prior to 1.8 joined all `build-depends`; as suggested by @ezyang it's easier for now to just fallback to legacy mode, than to add proper support for per-components builds for ancient cabal-spec versions Fixes #4121
-
- 18 Dec, 2016 4 commits
-
-
Andy Craze authored
adding ghc-prof-options to fprof warning
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
GHC will make use of this to do more accurate shadowing computation, because now we can tell if something is ABI-compatible, even if the 'id' matches. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
This is similar to what we do in Distribution.Simple.Build; preparatory commit so we can read out the ABI hashes of our dependencies from installedPkgs. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 17 Dec, 2016 1 commit
-
-
accraze authored
fixes #3718
-
- 14 Dec, 2016 1 commit
-
-
Mikhail Glushenkov authored
Bump directory upper bound
-
- 13 Dec, 2016 3 commits
-
-
Ben Gamari authored
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-