This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 09 Oct, 2016 1 commit
    • Andres Löh's avatar
      Adapt to changes in Distribution.Version. · 9bf8210a
      Andres Löh authored
      The DEBUG_TRACETREE debugging feature of cabal-install
      still had a call to 'showVersion' in it, which has been
      removed by recent changes to 'Distribution.Version'.
      9bf8210a
  2. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  3. 27 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `PackageName` type opaque (#3896) · dabd9d98
      Herbert Valerio Riedel authored
      When looking at heap-profiles of `cabal-install`, the `(:)` constructor
      stands out as the most-allocated constructor on the heap.
      
      Having to handle 10k+ package names contributes to the allocation
      numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
      per character footprint.
      
      This commit is a preparatory commit to pave the way for changing
      `PackageName`'s internal representation to something like
      `ShortByteString` (which is essentially a thin wrapper around primitive
      `ByteArray#`s which themselves have have an overhead of 2 words + one
      byte per ASCII character rounded up to nearest word) which would allow
      to reduce the memory footprint by a full order of magnitude, as well as
      reduce pointer chasing and GC overhead.
      dabd9d98
  4. 21 Sep, 2016 1 commit
    • Edward Z. Yang's avatar
      Don't solve for executables in legacy code path. · 9e99b3f4
      Edward Z. Yang authored
      
      
      There is a bug in `cabal configure`'s invocation of the solver in
      Distribution/Client/Configure.hs:
      
          standardInstallPolicy
              installedPkgIndex
              (SourcePackageDb mempty packagePrefs)
              [SpecificSourcePackage localPkg]
      
      We can see that the solver is given an EMPTY source package database.
      This is because we assume that everything you need from cabal configure
      is taken from the installed package index.
      
      But this is NOT true for executables, which never have an entry in the
      installed package index. So we SHOULD NOT solve for
      executables in the legacy codepath, since there isn't anything useful we
      can do with the info anyway.  This gets toggled using a new solver
      parameter SolveExecutables.
      
      I didn't bother with a test because this will be obsoleted by
      nix-local-build.
      
      Fixes #3875
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      9e99b3f4
  5. 18 Sep, 2016 1 commit
  6. 05 Sep, 2016 1 commit
    • kristenk's avatar
      Deduplicate build targets by storing them in a set. · f7533c35
      kristenk authored
      The solver can handle duplicate targets by linking them together, but the log
      is more complex, and the result is the same as if the targets were deduplicated
      beforehand.
      
      Duplicate targets can occur in a sandbox (issue #3203).
      f7533c35
  7. 04 Sep, 2016 1 commit
  8. 03 Aug, 2016 1 commit
  9. 03 Jul, 2016 1 commit
  10. 02 Jul, 2016 2 commits
  11. 27 Jun, 2016 2 commits
  12. 26 Jun, 2016 1 commit
  13. 07 May, 2016 1 commit
  14. 06 May, 2016 2 commits
  15. 26 Apr, 2016 1 commit
  16. 25 Apr, 2016 1 commit
  17. 24 Apr, 2016 2 commits
  18. 23 Apr, 2016 1 commit
  19. 05 Mar, 2016 1 commit
    • inaki's avatar
      Make the solver aware of pkg-config constraints · c72aa8db
      inaki authored
      When solving, we now discard plans that would involve packages with a
      pkgconfig-depends constraint which is not satisfiable with the current
      set of installed packages (as listed by pkg-config --list-all).
      
      This fixes https://github.com/haskell/cabal/issues/3016.
      
      It is possible (in principle, although it should be basically impossible
      in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to
      execute for various reasons, in particular because N is too large, so
      the command line becomes too long for the operating system limits.
      
      If this happens, revert to the previous behavior of accepting any
      install plan, regardless of any pkgconfig-depends constraints.
      c72aa8db
  20. 03 Mar, 2016 2 commits
    • Andres Löh's avatar
      Improve goal reorder heuristics. · 150d6ca9
      Andres Löh authored
      This change primarily does two things:
      
      1. For `--reorder-goals`, we use a dedicated datatype `Degree`
         rather than an `Int` to compute the approximate branching
         degree. We map 0 and 1 to the same value. We then use a
         lazy ordering and a shortcutting minimum function to look
         for the "best" goal.
      
         The motivation here is that we do not want to spend
         unnecessary work. Following any goal that has 0 or 1 as degree
         cannot really be "wrong", so we should not look at any others
         and waste time.
      
         This will still not always make the use of `--reorder-goals`
         better than not using it, but it will reduce the overhead
         introduced by it.
      
      2. We use partitioning rather than sorting for most of the other
         goal reordering heuristics that are active in all situations.
         I think this is slightly more straightforward and also slightly
         more efficient, whether `--reorder-goals` is used or not.
      
      I have run some preliminary performance comparisons and they
      seem to confirm that in both cases separately (with or without
      `--reorder-goals`), these changes are a relative improvement
      over the status quo. I will run additional tests before
      merging this into master.
      150d6ca9
    • Andres Löh's avatar
      Rename cycle detection phase and typos. · 64a014ec
      Andres Löh authored
      A number of small changes:
      
      - Some comment typos fixed.
      - The main function for cycle detection is now called
        `cycleDetectionPhase`, in analogy with all the other
        phases.
      
      I've run a superficial performance test trying to install
      all of Hackage on a clean db with ghc-7.10.3. This is not
      likely to trigger any situations where cycle detection
      actually kicks in, but it confirms in general that there is
      no negative performance (or correctness) impact for the
      common case.
      
      I've also considered moving the cycle detection phase to
      "earlier" in the solver, but after performance testing, decided
      against it, and documented the decision and the reasons in
      the code.
      64a014ec
  21. 20 Feb, 2016 1 commit
  22. 24 Jan, 2016 1 commit
  23. 17 Jan, 2016 1 commit
    • kristenk's avatar
      Fix space leak in solver backjumping · 8923a46d
      kristenk authored
      This commit refactors backjumping so that it uses the 'Progress' type instead of
      separate references to a node's children and the conflict set calculated from
      those children.
      8923a46d
  24. 17 Dec, 2015 1 commit
  25. 25 Nov, 2015 1 commit
    • Andres Löh's avatar
      Track language extensions and language flavours in the solver. · fd5e0c65
      Andres Löh authored
      Every package now "depends" on all language extensions
      (default-extensions and other-extensions) and language flavours
      (default-language and other-languages) it declares in its cabal file.
      
      During solving, we verify that the compiler we use actually
      supports selected extensions and languages. This has to be done
      during solving, because flag choices can influence the declared
      extensions and languages being used.
      
      There currently is no equivalent check performed on the generated
      install plans. In general, cabal-install performs a sanity check
      on the solver output, checking that the solver e.g. indeed includes
      all the declared dependencies of a package. There is no such
      double-checking for language extensions. This is not really
      problematic, as all that this change does is to make the solver
      more conservative rather than less. However, having a sanity check
      available might ultimately be nice to have.
      fd5e0c65
  26. 31 Jul, 2015 1 commit
  27. 01 Jun, 2015 1 commit
  28. 06 Apr, 2015 1 commit
  29. 27 Mar, 2015 4 commits
  30. 09 Jun, 2014 2 commits
    • Herbert Valerio Riedel's avatar
      Allow template-haskell to be upgradable again · ffd67e5e
      Herbert Valerio Riedel authored
      This partly reverts 65e9b88b
      which marked `template-haskell` non-upgradable. However, since are now
      able to fix-up wrong .cabal meta-data on Hackage, previous `template-haskell`
      releases have been augmented by proper version bounds so that it's now
      safe again to let the Cabal solver handle reinstalling `template-haskell`
      
      See also #1811, #667, #1761, and #1444
      
      (cherry picked from commit 65ae95c1 / #1934)
      ffd67e5e
    • Herbert Valerio Riedel's avatar
      Allow template-haskell to be upgradable again · 65ae95c1
      Herbert Valerio Riedel authored
      This partly reverts 65e9b88b
      which marked `template-haskell` non-upgradable. However, since are now
      able to fix-up wrong .cabal meta-data on Hackage, previous `template-haskell`
      releases have been augmented by proper version bounds so that it's now
      safe again to let the Cabal solver handle reinstalling `template-haskell`
      
      See also #1811, #667, #1761, and #1444
      65ae95c1
  31. 23 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · f950e8d7
      Andres Löh authored and tibbe's avatar tibbe committed
      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