This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 24 Jun, 2014 1 commit
  2. 11 Jun, 2014 1 commit
  3. 10 Jun, 2014 1 commit
  4. 09 Jun, 2014 2 commits
  5. 07 Jun, 2014 1 commit
  6. 29 May, 2014 1 commit
  7. 28 May, 2014 1 commit
  8. 26 May, 2014 2 commits
  9. 24 May, 2014 2 commits
  10. 23 May, 2014 2 commits
    • Andres Löh's avatar
      Configurable strong/weak flags. · f950e8d7
      Andres Löh authored
      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
    • Andres Löh's avatar
      Treat flags with much less priority. · 5e7c7f69
      Andres Löh authored
      This implements two changes:
      
      (1) Flag choices are deferred whenever possible.
      (2) If a package appears on both branches of a conditional, the
          unconstrained package is lifted out of the conditional.
      
      In combination, we're trying to achieve that the solver should pick
      a package before the flag, and thereby e.g. respect installed package
      versions.
      
      This is adequate in the common use case that flags are simply
      representing a disjunction, and should be rather weak.
      
      We'll have to see what happens in the few other situations where flags
      are really representing optional features. I'd expect, however, that
      in such situations there are targets in one branch, and not the other.
      Then the flag choice would still happen prior to the corresponding
      target.
      
      (cherry picked from commit 91abc4f9)
      5e7c7f69
  11. 20 May, 2014 8 commits
    • ttuegel's avatar
      Always stream test output concurrently · e7236056
      ttuegel authored
      Issue #1810. Some test suites would freeze if invoked with
      `--show-details=always` instead of `--show-details=streaming` because
      output would build up in the pipe without being cleared. This corrects
      the issue by forcing the length of the output string in another thread.
      
      (cherry picked from commit e5a07013)
      e7236056
    • ttuegel's avatar
      Merge pull request #1882 from ttuegel/tests-freeze · fb778e3c
      ttuegel authored
      Always stream test output concurrently
      fb778e3c
    • ttuegel's avatar
      Always stream test output concurrently · e5a07013
      ttuegel authored
      Issue #1810. Some test suites would freeze if invoked with
      `--show-details=always` instead of `--show-details=streaming` because
      output would build up in the pipe without being cleared. This corrects
      the issue by forcing the length of the output string in another thread.
      e5a07013
    • tibbe's avatar
      Merge branch 'defer-flags' of https://github.com/kosmikus/cabal · 3388fff7
      tibbe authored
      Conflicts:
      	cabal-install/Distribution/Client/Freeze.hs
      3388fff7
    • Andres Löh's avatar
      Fix flag goal generation (and hopefully #1855). · a57fe48d
      Andres Löh authored
      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
    • Andres Löh's avatar
      Fix a flag-handling bug related to #1855. · 5b58dc88
      Andres Löh authored
      This was an innocent-looking but severe bug that was triggered for manual
      flags in certain circumstances: if both choices of a manual flag are
      already invalidated by other decisions, then the old code was removing
      the nodes underneath the flag completely. As a result, there's a node
      with no children rather than a node with two failure-children. The
      fail-nodes carry important information that is used to compute how far
      we can backtrack. If this information is removed, strange things happen.
      
      (cherry picked from commit 3e33a0f3)
      5b58dc88
    • tibbe's avatar
    • Mikhail Glushenkov's avatar
      Merge pull request #1853 from benarmston/freeze-test-and-benchmark-deps · 7732306a
      Mikhail Glushenkov authored
      Add --enable-{tests,benchmarks} to freeze command
      7732306a
  12. 19 May, 2014 5 commits
    • Andres Löh's avatar
      Configurable strong/weak flags. · 3dcddea4
      Andres Löh authored
      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.
      3dcddea4
    • Andres Löh's avatar
      Treat flags with much less priority. · 91abc4f9
      Andres Löh authored
      This implements two changes:
      
      (1) Flag choices are deferred whenever possible.
      (2) If a package appears on both branches of a conditional, the
          unconstrained package is lifted out of the conditional.
      
      In combination, we're trying to achieve that the solver should pick
      a package before the flag, and thereby e.g. respect installed package
      versions.
      
      This is adequate in the common use case that flags are simply
      representing a disjunction, and should be rather weak.
      
      We'll have to see what happens in the few other situations where flags
      are really representing optional features. I'd expect, however, that
      in such situations there are targets in one branch, and not the other.
      Then the flag choice would still happen prior to the corresponding
      target.
      91abc4f9
    • Andres Löh's avatar
      Fix flag goal generation (and hopefully #1855). · a51b8378
      Andres Löh authored
      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).
      a51b8378
    • Andres Löh's avatar
      Fix a flag-handling bug related to #1855. · 3e33a0f3
      Andres Löh authored
      This was an innocent-looking but severe bug that was triggered for manual
      flags in certain circumstances: if both choices of a manual flag are
      already invalidated by other decisions, then the old code was removing
      the nodes underneath the flag completely. As a result, there's a node
      with no children rather than a node with two failure-children. The
      fail-nodes carry important information that is used to compute how far
      we can backtrack. If this information is removed, strange things happen.
      3e33a0f3
    • Mikhail Glushenkov's avatar
      Increase defaultMaxBackjumps to 2000 (from 200). · 0229cd52
      Mikhail Glushenkov authored
      As suggested by Anders Löh in #1780.
      
      (cherry picked from commit e2b481a0)
      0229cd52
  13. 15 May, 2014 1 commit
  14. 14 May, 2014 3 commits
    • barmston's avatar
      Tests for the freeze command · c2032b67
      barmston authored
      Introduced a new test-suite, package-tests, which is intended for black-box
      testing of the cabal binary.
      
      The `PackageTests` module determines which cabal binary is to be tested and
      runs the tests passing each of them the path to that binary. The binary is the
      first cabal binary found on the path. To test a different binary, adjust the
      PATH environment variable.
      
      The `PackageTests.PackageTester` module contains common routines to execute
      the cabal binary and check its results.
      
      Finally, the `PackageTests.Freeze.Check` command contains some tests for the
      freeze command.
      c2032b67
    • barmston's avatar
      Add --enable-{tests,benchmarks} to freeze command · a9dc1996
      barmston authored
      If they are present the dependencies of all test and benchmark stanzas are
      included in the frozen set of dependencies.
      a9dc1996
    • Thomas M. DuBuisson's avatar
      Re-order CC options. · 9d7a8ff9
      Thomas M. DuBuisson authored
      A default -O2 coming second over-rides packages that specify -O3.
      Among other issues, this means expected AVX instructions are not being
      generated and performance takes orders of magnitude dive in some cases.
      9d7a8ff9
  15. 13 May, 2014 1 commit
  16. 12 May, 2014 4 commits
  17. 11 May, 2014 1 commit
  18. 10 May, 2014 3 commits
    • Iain Nicol's avatar
      Fix: "cabal haddock" uses CPP overzealously · ba4ae3d0
      Iain Nicol authored
      Until recently we supported ancient versions of Haddock, pre v2.0.  To
      support the CPP extension with such versions, cabal had to invoke the
      CPP before invoking Haddock on the output.  For simplicity cabal would
      invoke the CPP on all Haskell files, if any Haskell file required CPP.
      However, invoking CPP on a file which does not require it can cause
      build failures.
      
      Haddock v2.0+ supports the CPP via GHC, and even automatically
      preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
      simply need only tell Haddock to enable the CPP when the CPP is a
      package level default extension.
      
      Fixes issue #1808.
      ba4ae3d0
    • Iain Nicol's avatar
      Use Haddock's builtin support for .lhs and CPP · 5729bc5c
      Iain Nicol authored
      This is a code simplification on our end.
      
      Thanks to Mikhail Glushenkov for the suggestion.
      5729bc5c
    • Iain Nicol's avatar
      Remove support for Haddock versions < 2.0 · 98c537f1
      Iain Nicol authored
      Dropping this support is unlikely to be a problem in practice.  Debian
      oldstable is currently on version 2.6.0 of Haddock, for example.
      
      This change enables future code simplification.  Currently we
      preprocess both Haskell files requiring the CPP and Literate Haskell
      files; newer versions of Haddock can handle these natively.
      
      Fixes issue #1718.
      98c537f1