This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Jun, 2018 1 commit
  2. 09 May, 2018 1 commit
  3. 08 May, 2018 1 commit
    • quasicomputational's avatar
      Allow ** wildcards in globs. · 5e83ef26
      quasicomputational authored
      These are inspired by a plan described in a comment in #2522, and only
      implement a quite limited form of recursive matching: only a single **
      wildcard is accepted, it must be the final directory, and, if a **
      wildcard is present, the file name must include a wildcard.
      
      Or-patterns are not implemented, for simplicity.
      
      Closes #3178, #2030.
      5e83ef26
  4. 19 Apr, 2018 1 commit
    • lspitzner's avatar
      Fix cabal project caching bug, Fix provenance tracking · 4818eb5c
      lspitzner authored
      - Use (projectConfigPath, distProjectFile "") as key
        for config FileMonitor, instead of ().
      - Provenances were previously not tracked for "local" and
        "freeze" configs.
      - Add verbose printing of relevant config file paths.
      
      Fixes #4662 and probably #5225
      4818eb5c
  5. 16 Apr, 2018 1 commit
    • Samuel Gélineau's avatar
      fix infinite loop in D.Client.TargetSelector · 7ecff6e3
      Samuel Gélineau authored
      The pattern guard was clearly meant as a list-comprehension filter,
      but on a let-bound pattern, it instead caused a circular loop in which
      whether the LHS variables are bound the the RHS values depends on the
      values of the LHS variables.
      
      fixes #5081
      7ecff6e3
  6. 10 Apr, 2018 1 commit
  7. 05 Apr, 2018 1 commit
  8. 28 Mar, 2018 3 commits
  9. 27 Mar, 2018 1 commit
  10. 26 Mar, 2018 1 commit
    • alexbiehl's avatar
      Haddock: Generate haddock for components · 4466310e
      alexbiehl authored
      Currently settings `documentation: true` enables documentation
      generation via haddock for your whole package, including tests and benchmarks.
      However, there are additional flags to control generation of
      documentation for this "second class" documentation targets, which are
      currently not honored at the cabal-install side of things. Namely,
      `tests`, `benchmarks`, `executables`, etc. provided under the
      `haddock` section in your `$CABAL_HOME/config`.
      
      This patch adds a more sensible approach to documentation generation
      via haddock. Also enabling `new-haddock` to generate documentation for
      single components instead whole packages.
      
      The behaviour works like this:
      
          - Setting `documentation: true` or passing
            `--enable-documentation` to cabal-install enable documentation
            for any component in the build plan honoring the respective
            flags for tests, benchmarks, exes, foreignlibs, etc.
      
          - Invoking new-haddock with a target selector will make sure
            the respective flags for "second class" doc targets are set
            correctly. E.g.
      
            $ new-haddock tests
      
            Will generate documentation for the testsuite of your package
            event if you have `tests: false` in your haddock section.
      4466310e
  11. 25 Mar, 2018 1 commit
  12. 22 Mar, 2018 1 commit
  13. 13 Mar, 2018 2 commits
  14. 11 Mar, 2018 3 commits
  15. 10 Mar, 2018 3 commits
  16. 09 Mar, 2018 1 commit
  17. 06 Mar, 2018 3 commits
  18. 05 Mar, 2018 3 commits
  19. 03 Mar, 2018 2 commits
    • Herbert Valerio Riedel's avatar
      Set upper bound on setup.Cabal relative to current version · c92b7150
      Herbert Valerio Riedel authored
      As we can't predict the future, we also place a global upper
      bound on the lib:Cabal version we know how to interact with:
      
      The upper bound is computed by incrementing the current major
      version twice in order to allow for the current version, as
      well as the next adjacent major version (one of which will not
      be released, as only "even major" versions of Cabal are
      released to Hackage or bundled with proper GHC releases).
      
      For instance, if the current version of cabal-install is an odd
      development version, e.g.  Cabal-2.1.0.0, then we impose an
      upper bound `setup.Cabal < 2.3`; if `cabal-install` is on a
      stable/release even version, e.g. Cabal-2.2.1.0, the upper
      bound is `setup.Cabal < 2.4`. This gives us enough flexibility
      when dealing with development snapshots of Cabal and cabal-install.
      
      This addresses #415
      
      (cherry picked from commit e66106c7)
      c92b7150
    • Herbert Valerio Riedel's avatar
      Fine-tune lower bound on lib:Cabal · de880a54
      Herbert Valerio Riedel authored
      GHC 8.4.1-rc1 (GHC 8.4.0.20180224) unfortunately still shipped with a
      devel snapshot of Cabal-2.1.0.0; but GHC 8.4.1 final will ship w/
      lib:Cabal-2.2.0.0
      
      (cherry picked from commit 5066672f)
      de880a54
  20. 26 Feb, 2018 2 commits
  21. 24 Feb, 2018 1 commit
    • Herbert Valerio Riedel's avatar
      Implement ghc/cabal compatiblity matrix (re #415) · 71e797ea
      Herbert Valerio Riedel authored
      This injects lower-bound constraints on Cabal for custom setup
      dependencies to prevent the solver from selecting unsupported
      configurations.
      
      Previously we already added an absolute lower bound `Cabal >= 1.20`
      for nix-local builds, as that's the minimum version we need to be able
      to interact with custom Setup.hs scripts. This refines with logic by
      restricting that lower bound even more based on GHC version.
      
      This patch augments this with the following rules:
      
      - GHC 8.4+   constrains  Cabal >= 2.2
      - GHC 8.2    constrains  Cabal >= 2.0
      - GHC 8.0    constrains  Cabal >= 1.24
      - GHC 7.10   constrains  Cabal >= 1.22
      - (default   constraint  Cabal >= 1.20)
      
      This only affects nix-style local builds codepaths.
      71e797ea
  22. 13 Feb, 2018 2 commits
  23. 12 Feb, 2018 3 commits
  24. 10 Feb, 2018 1 commit
    • Moritz Angermann's avatar
      Read basedir from cabal-file, and thread it through apropriately. · af49513d
      Moritz Angermann authored
      If we have a cabalFilePath, just invoke the configure script there.  Otherwise
      try to invoke it locally to the CWD.  But don't try to shell out in a different
      directory, that would mess up the paths.  In general we want to run
      /path/to/configure from the bulid directory (e.g. outside of the package folder).
      af49513d