This project is mirrored from Pull mirroring updated .
  1. 25 Nov, 2015 2 commits
    • Danny Navarro's avatar
      Add solver tests for language extensions and flavours · 1f40772a
      Danny Navarro authored
      This also includes modifications to the solver testing DSL and the
      testing functions.
      This is necessary for merging PR #2732.
    • 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.
  2. 23 Nov, 2015 1 commit
  3. 17 Nov, 2015 4 commits
  4. 16 Nov, 2015 3 commits
  5. 15 Nov, 2015 3 commits
  6. 13 Nov, 2015 6 commits
  7. 12 Nov, 2015 2 commits
  8. 10 Nov, 2015 1 commit
    • ben0x539's avatar
      Make `cabal init` reject extra arguments. · 2b719a52
      ben0x539 authored
      This is better than ignoring them because one is likely in some state of
      confusion when passing extraneous arguments to `cabal init` and would
      probably appreciate being taken out of that state sooner rather than
  9. 07 Nov, 2015 2 commits
    • ttuegel's avatar
      Merge pull request #2913 from nomeata/show-details-direct · e99ed843
      ttuegel authored
      Show details direct
    • Joachim Breitner's avatar
      test: New mode --show-details=direct · 2542325e
      Joachim Breitner authored
      This mode implements #2911, and allows to connect the test runner
      directly to stdout/stdin. This is more reliable in the presence of no
      threading, i.e. a work-arond for #2398.
      I make the test suite use this, so that it passes again, despite
      printing lots of stuff. Once #2398 is fixed properly, the test suite
      should probably be extended to test all the various --show-details
  10. 06 Nov, 2015 2 commits
  11. 05 Nov, 2015 5 commits
  12. 04 Nov, 2015 5 commits
  13. 03 Nov, 2015 1 commit
  14. 02 Nov, 2015 3 commits
    • Andres Löh's avatar
      Merge pull request #2906 from dcoutts/master · f2278fc2
      Andres Löh authored
      Solver: limit where package target constraints apply
    • Duncan Coutts's avatar
      Solver: limit where package target constraints apply · 13dceb5b
      Duncan Coutts authored
      When we have a target like "foo-1.0", in terms of solver input this
      gets turned into a target package name of "foo" and a (labelled)
      constraint of "foo == 1.0". This constraint is of course to ensure
      that we pick the right target. However, with the recent addition of
      qualified package goals we have the possibility of picking multiple
      versions of the same package (e.g. via setup deps). If we have a
      constraint like "foo == 1.0" apply everywhere then it becomes
      impossible to pick multiple versions of package "foo", which may
      mean we cannot find a solution at all. But the constraint for the
      target need not apply everywhere, it's just to ensure that for the
      "main" instance, we pick the right version.
      This patch makes that precise. We have these constraints arising
      from targets apply only to package name goals that are suitably
      unqualified: qualifications arising from independent goals and from
      base version trickery are ok, but qualifiactions from setup deps
      are not. Or to put it another way, these target constraints do not
      apply to goals arising as the result of setup dependencies.
      As a more concrete example, this allows a situation where a package
      needs an old version of Cabal as a setup dep, but a new version of
      Cabal is also present in the main part of the solution as a normal
      library dep. Whenever we solve for that main Cabal lib as a target
      it would previously fail (it would be impossible to satisfy the
      conflicting constraints on the Cabal setup dep) and it now works.
    • Herbert Valerio Riedel's avatar
      Relax upper bound on process to allow process-1.4 · 75d2807a
      Herbert Valerio Riedel authored
      The only change between process 1.3 and 1.4 is:
      "Added child_user and child_group to CreateProcess for unix. #45"
      And the relevant code in Cabal doesn't seem affected by those additional