This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 18 Oct, 2014 1 commit
  2. 07 Oct, 2014 3 commits
  3. 18 Sep, 2014 1 commit
  4. 27 Aug, 2014 1 commit
    • Duncan Coutts's avatar
      Change rep of module re-exports, and do resolution ourselves · a3d3273a
      Duncan Coutts authored
      The initial support for module re-exports relied on ghc-pkg to resolve
      user-specified re-exports to references to specific installed packages.
      This resolution is something that can fail so it's better for Cabal to
      do it during the package configure phase.
      
      In addition, it is inconvenient in ghc-pkg to be doing this resolution,
      and it just seems fishy as a design. Also, the same ModuleExport type
      was being used both for user-specified source re-exports and also for
      the specific re-exports in the package db.
      
      This patch splits the type into two: one for source level, and one for
      resolved ones for use in the package db. The configure phase resolves
      one to the other.
      
      One minor change: it is now possible to re-export a module defined in
      the same package that is not itself exported (ie it's in other-modules,
      rather than exposed-modules). Previously for modules definied in the
      same package they had to be themselves exported. Of course for
      re-exports from other packages they have to be exposed.
      a3d3273a
  5. 16 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Implement "reexported-modules" field, towards fixing GHC bug #8407. · 62450f9a
      Edward Z. Yang authored
      
      
      Re-exported modules allow packages to reexport modules from their
      dependencies without having to create stub files.  Reexports of the same
      original module don't count as ambiguous imports when module finding
      occurs.  The syntax is:
      
          "orig-pkg" OrigName as NewName
      
      You can omit 'as NewName', in which case it is reexported as the same
      name.  Self referential aliases work too; however, they're only visible
      to packages which depend on this package.
      
      Left to future work: just provide a module name 'OrigName', where ghc-pkg
      figures out what the source package is.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      62450f9a
  6. 12 Jun, 2014 1 commit
  7. 14 Apr, 2014 1 commit
  8. 02 Feb, 2014 1 commit
  9. 08 Jan, 2014 1 commit
    • Duncan Coutts's avatar
      New license-files field. · a7b58b1f
      Duncan Coutts authored
      Based closely on the patches by Mathieu Boespflug <mboes@cs.mcgill.ca>
      
      This field is intended to be used instead of (or in addition to) the
      normal 'license-file' field by packages that have multiple files for
      their license material. This is useful when eg the license is
      supplemented by additional permissions and/or conditions. Notably,
      the LGPL is structured in this way: it amends the GPL with additional
      permissions, therefore one should distribute both the GPL in COPYING
      and the LGPL in COPYING.LESSER.
      
      So we keep both the license-file and license-files fields (rather than
      deprecating one) and packages can use either or a mixture.
      a7b58b1f
  10. 28 Oct, 2013 1 commit
  11. 21 Aug, 2013 1 commit
  12. 06 Jun, 2013 1 commit
  13. 25 Mar, 2013 1 commit
  14. 06 Mar, 2013 1 commit
  15. 14 Jan, 2013 1 commit
    • John Wiegley's avatar
      Add extra-html-files, for installing extra html files · 49a2be96
      John Wiegley authored
      For example, you might have an images/ directory in your project, with
      images that you refer to from Haddock with:
      
          <<images/foo.png>>
      
      Then in your Cabal file you would include:
      
          extra-html-files: images/*.png
      
      And these would both be packaged by sdist, and "cabal haddock" will
      install them in:
      
          ~/.cabal/share/doc/PROJECT/html/images/*.png
      
      Fixes #1167
      49a2be96
  16. 10 Dec, 2012 2 commits
    • Duncan Coutts's avatar
      Add a check for main-is C files, only ok with cabal-version >= 1.18 · c70f9e35
      Duncan Coutts authored
      For compatability, we need to make sure people using C files for the
      main-is field, also have to specify the right cabal version.
      c70f9e35
    • Duncan Coutts's avatar
      Support for C/C++/Obj-C as main · de88f409
      Duncan Coutts authored
      This allows specifying the main-is field as a C file.
      
      This is closely based on patches by Edward Z. Yang, who in turn credits
      and earlier set of patches by Irene Knapp. The slight difference in
      this version of the patch is that it is adjusted to work with the new
      approach where we have separate hs compile; c compile; and link phases.
      de88f409
  17. 24 Nov, 2012 1 commit
    • refold's avatar
      Typo. · a079a1af
      refold authored
      a079a1af
  18. 03 Nov, 2012 1 commit
  19. 25 Jun, 2012 1 commit
  20. 24 Jun, 2012 1 commit
  21. 28 Apr, 2012 1 commit
    • Iustin Pop's avatar
      Add Apache license as a known license · 1d9a0286
      Iustin Pop authored
      This patch adds the Apache license (http://www.apache.org/licenses/)
      as a versioned license. Only version 2.0 is added, as the others are
      historical and should not be used.
      
      I've also updated slightly the license parse test, but I'm not sure
      that the instructions for running the tests are correct (I don't see
      the "license parsers" test being shown when running
      ./test/dist/build/suite/suite).
      1d9a0286
  22. 12 Oct, 2011 1 commit
    • tibbe's avatar
      Add package checks for benchmarks · 1eac8847
      tibbe authored
      Refactor duplicate names check to avoid having to manually write all
      O(n^2) possible collision cases between executables, test suites, and
      benchmarks.
      1eac8847
  23. 23 Oct, 2011 1 commit
  24. 05 Sep, 2011 1 commit
  25. 19 Jun, 2011 1 commit
  26. 29 Jan, 2011 1 commit
    • Duncan Coutts's avatar
      Relax QA check on test-suite sections to require only Cabal 1.8 · 4108560f
      Duncan Coutts authored
      Only Cabal-1.10 and later can use test suites. Versions of Cabal prior
      to 1.8 actually barf on test-suite sections, while Cabal-1.8 will
      ignore these sections with a warning. Previously the QA check enforced
      that packages with test-suite section specify 'cabal-version: >= 1.10'
      but strictly speaking we only need to require 'cabal-version: >= 1.8'.
      This relaxation allows people to write packages using test suites such
      that people using Cabal-1.8 will be able to build and install the
      package, just not run the test suite. Clear as mud?
      4108560f
  27. 26 Oct, 2010 2 commits
  28. 25 Oct, 2010 1 commit
  29. 18 Oct, 2010 2 commits
  30. 16 Oct, 2010 2 commits
  31. 13 Oct, 2010 3 commits
    • Duncan Coutts's avatar
      Update the message for a package check · 74741297
      Duncan Coutts authored
      74741297
    • Duncan Coutts's avatar
      Add a few TODOs about package checks · 19ea3cde
      Duncan Coutts authored
      19ea3cde
    • Duncan Coutts's avatar
      Change the syntax and behaviour of the cabal-version field · 520b3481
      Duncan Coutts authored
      For historical reasons the cabal-version is specified with a version range,
      to indicate the range of versions of tools that the package will work with.
      We now think it makes more sense to specify the version of the Cabal spec
      that the package follows. Old Cabal versions will not be able to parse simple
      versions in this field. So we initially make the parser allow plain versions
      but then we add a check to warn about using it prior to Cabal-1.12 at which
      point it will be allowed.
      Added a check about using version ranges that are not of the form '>= x.y'.
      Also change behaviour to ignore upper bounds in the given version range.
      520b3481
  32. 10 Oct, 2010 1 commit