This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 24 Jun, 2014 1 commit
    • Andres Löh's avatar
      Treat all flags of a package as interdependent. · 5b63fce6
      Andres Löh authored and tibbe's avatar tibbe committed
      There was an open bug that could cause conflict sets to be
      computed incorrectly if flags were involved in the conflict
      set. Incorrectly computed conflict sets can lead to the solver not
      finding solutions even though they actually exist.
      
      Because I decided that computing flag dependencies correctly is tricky
      and probably not worth the effort, we're now treating all flags (of a
      package) as mutually dependent. This means that if any flag choice ends
      up in a conflict set, then it's as if all flag choices (of the same
      package) are in that conflict set. This is potentially slower for
      packages having many flags, but it should at least be correct, because
      it's conservative.
      
      (cherry picked from commit 3f777568)
      5b63fce6
  2. 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
  3. 20 May, 2014 1 commit
    • Andres Löh's avatar
      Fix flag goal generation (and hopefully #1855). · a57fe48d
      Andres Löh authored and tibbe's avatar tibbe committed
      Package flags generate (Boolean) goals. Package flags can be dependent
      on one another, in situations such as this one:
      
        if flag(a)
          ...
        else
          if flag(b)
            ...
          else
            ...
      
      In such a scenario, it's important to record that flag b depends on flag
      a. This affects conflict set generation. If something fails due to the
      choice of flag b, we should not backjump beyond flag a.
      
      While the code handling the proper insertion of goals with their correct
      dependencies was always there, it was accidentally overridden by another
      piece of code that created flag goals (without dependencies) for all
      flags defined in a package. The reason I add flag goals separately is
      because not all paths in the decision tree may contain choices for all
      flags of a package. For example, if a is chosen to be True in the
      example above, b does not occur at all. But flag choices may still
      affect other things that aren't visible to the solver (directory
      choices, exposed modules, ...), so all flags declared should always be
      chosen explicitly. So we want to keep adding all flags declared in a
      package as dummies, but we have to make sure to do so *before* adding
      the actual dependency tree. This way, while traversing the dependency
      tree, the ones occurring in dependencies will be added again, overriding
      the dummies, rather than the other way round (which we used to have
      before, where the dummies were overwriting the more informative
      versions).
      
      (cherry picked from commit a51b8378)
      a57fe48d
  4. 16 Nov, 2012 1 commit
  5. 31 May, 2012 2 commits
  6. 05 Apr, 2012 1 commit
    • Andres Löh's avatar
      adding the possibility for index-disabled packages · 7db70840
      Andres Löh authored
      In the modular solver, it's now possible to mark packages
      as disabled in the index conversion phase. This can be used
      to mark broken packages (with missing dependencies) in such
      a way that they can still be seen by the solver and reported
      in error messages.
      
      Furthermore, the feature could be used to implement
      shadowing restrictions. Currently, there are some things
      that can go wrong if multiple installed instances of
      the same version and package exist on the system. However,
      I've not enabled the use of shadowing for now, as it's
      hard to match the restrictions exactly, and we can end up
      excluding perfectly valid cases. Enabling shadowing
      selectively by a solver flag would be an option.
      7db70840
  7. 15 Mar, 2012 1 commit
  8. 12 Feb, 2012 1 commit
  9. 29 Oct, 2011 1 commit
  10. 27 Oct, 2011 1 commit
  11. 09 Jul, 2011 1 commit
  12. 03 Jul, 2011 2 commits
  13. 21 Jun, 2011 1 commit
    • Andres Löh's avatar
      maintain chains of GoalReasons · 2eab1f8e
      Andres Löh authored
      Bugfix: conflict sets now contain the transitive closure of goal reasons,
      which is required for completeness.
      
      We now finally have sufficient info to produce good error messages, too.
      At a failure site, we can trace which parts of the tree are relevant to
      the failure, via the correctly generated conflict sets.
      2eab1f8e
  14. 20 Jun, 2011 7 commits
  15. 15 Jun, 2011 1 commit