This project is mirrored from Pull mirroring updated .
  1. 22 Apr, 2016 2 commits
  2. 21 Apr, 2016 3 commits
    • kristenk's avatar
      Use larger conflict set when solver chooses wrong version for package in link group · 7f480594
      kristenk authored and Edsko de Vries's avatar Edsko de Vries committed
      This commit replaces a call to 'lgBlame' with a call to 'lgConflictSet'.
      'lgConflictSet' adds the members of the link group to the conflict set. The
      other members are required, for example, when a linked package's version doesn't
      match a constraint, and the solver must try other versions for the linked-to
      All tests now pass.
    • Edsko de Vries's avatar
      Fix bug in link validation · 34bfdf82
      Edsko de Vries authored
      When we are choosing to link a package (`pickLink`), it is possible that that
      package was _already_ linked (because its reverse dependencies got linked).
      Thus, this requires a merge of link groups: it is not correct to simply add the
      package into the target link group.
      This fixes #2842.
    • Andres Löh's avatar
      Remove goal reason chains. · 7995ea2a
      Andres Löh authored and Edsko de Vries's avatar Edsko de Vries committed
  3. 18 Apr, 2016 1 commit
  4. 17 Apr, 2016 1 commit
    • Edsko de Vries's avatar
      Make ConflictSet abstract · 1a1f1f9b
      Edsko de Vries authored
      This commit is a pure refactoring, no semantic changes. Submitting as separate
      PR at @kosmikus request.
      Tihs moves `ConflictSet` and `Var` into their own modules.
  5. 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
      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.
  6. 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.
  7. 01 Jun, 2015 5 commits
  8. 07 Apr, 2015 2 commits
  9. 06 Apr, 2015 1 commit
  10. 31 Mar, 2015 1 commit
    • Edsko de Vries's avatar
      Fine-grained dependencies in solver input · a5a823d4
      Edsko de Vries authored
      The modular solver has its own representation for a package (PInfo). In this
      commit we modify PInfo to keep track of the different kinds of dependencies.
      This is a bit intricate because the solver also regards top-level goals as
      dependencies, but of course those dependencies are not part of any 'component'
      as such, unlike "real" dependencies. We model this by adding a type parameter
      to FlaggedDeps and go which indicates whether or not we have component
      information; crucially, underneath flag choices we _always_ have component
      information available.
      Consequently, the modular solver itself will not make use of the ComponentDeps
      datatype (but only using the Component type, classifying components); we will
      use ComponentDeps when we translate out of the results from the modular solver
      into cabal-install's main datatypes.
      We don't yet _return_ fine-grained dependencies from the solver; this will be
      the subject of the next commit.
  11. 27 Mar, 2015 2 commits