This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 19 May, 2014 2 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
  2. 14 May, 2014 1 commit
    • 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
  3. 13 May, 2014 1 commit
  4. 12 May, 2014 4 commits
  5. 11 May, 2014 1 commit
  6. 10 May, 2014 5 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
    • Iain Nicol's avatar
      a718eb07
    • Iain Nicol's avatar
      Add some tests of our Haddock support · 5bcb6f76
      Iain Nicol authored
      5bcb6f76
  7. 09 May, 2014 1 commit
  8. 08 May, 2014 1 commit
  9. 03 May, 2014 2 commits
  10. 01 May, 2014 2 commits
  11. 27 Apr, 2014 3 commits
  12. 26 Apr, 2014 2 commits
  13. 24 Apr, 2014 6 commits
  14. 23 Apr, 2014 6 commits
  15. 22 Apr, 2014 3 commits