This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 04 Mar, 2015 1 commit
  2. 10 Dec, 2014 2 commits
  3. 30 Oct, 2014 1 commit
  4. 25 Sep, 2014 2 commits
  5. 04 Aug, 2014 1 commit
  6. 14 Apr, 2014 1 commit
  7. 16 Feb, 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. 09 Sep, 2013 1 commit
  11. 05 Sep, 2013 1 commit
  12. 17 Jul, 2013 1 commit
  13. 03 Jun, 2013 1 commit
  14. 02 May, 2013 3 commits
  15. 26 Apr, 2013 2 commits
  16. 23 Apr, 2013 1 commit
  17. 14 Jan, 2013 2 commits
    • John Wiegley's avatar
      A few more code simplifications · 2ff85140
      John Wiegley authored
      2ff85140
    • 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
  18. 26 Nov, 2012 1 commit
  19. 14 Nov, 2012 1 commit
  20. 08 Nov, 2012 1 commit
  21. 26 Sep, 2012 1 commit
  22. 23 Oct, 2011 1 commit
  23. 12 Oct, 2011 1 commit
  24. 23 Sep, 2011 1 commit
  25. 08 Jul, 2011 1 commit
    • Duncan Coutts's avatar
      Fix withComponentsLBI and move Components to LocalBuildInfo module · 1c20a632
      Duncan Coutts authored
      An annoyance of the current Simple build system is that each phase
      (build, install, etc) can be passed additional HookedBuildInfo which
      gets merged into the PackageDescription. This means that we cannot
      process the PackageDescription up front at configure time and just
      store and reuse it later, we have to work from it each time afresh.
      
      The recent addition of Components (libs, exes, test suites) and a
      topoligical sort of the components in the LocalBuildInfo fell foul
      of this annoyance. The LocalBuildInfo stored the entire component
      which meant they were not updated with the HookedBuildInfo. This
      broke packages with custom Setup.hs scripts that took advantage of
      the HookedBuildInfo feature, including those with configure scripts.
      
      The solution is to store not the list of whole components but the
      list of component names. Then withComponentsLBI retrieves the actual
      components from the PackageDescription which thus includes the
      HookedBuildInfo.
      
      Also moved the Components into an internal module because (for the
      moment at least) it is part of the Simple build system, not part of
      the package description.
      1c20a632
  26. 19 Jun, 2011 1 commit
  27. 05 May, 2011 1 commit
    • intractable's avatar
      intrapackage-deps-and-per-component-preprocessing · 2e348126
      intractable authored
      This patch adds intrapackage dependency resolution so that components
      (libraries, exes, test suites) are build in the correct order.  This mean it's
      now possible to have, e.g., executables that depend on other executables defined
      in the same package description: the build-tools namespace has been extended
      accordingly.
        
      Related to this change is the refactoring of the do-it-all preprocessSources
      function, formerly invoked by initialBuildSteps, into a a function
      preprocessComponent that is invoked when a component is being built.  This lets
      us use executables defined in a package to be used as a custom preprocessor when
      building other components.
        
      Finally, a number of functions now operate on values of the sum type
      PackageDescription.Component rather than specifically operating on Library or
      Executable and so forth.
      2e348126
  28. 15 Apr, 2011 1 commit
    • Duncan Coutts's avatar
      Implement Setup sdist --output-directory=dir · e41906a7
      Duncan Coutts authored
      That is, allow generating a dir tree rather than a tarball.
      Apart from being useful directly, this is the right approach for
      tools like cabal-install. cabal-install does the tar step itself
      and might like to do other things like zip format.
      Also cleaned up the sdist code a little.
      e41906a7
  29. 19 Jan, 2011 1 commit
  30. 17 Jan, 2011 2 commits
  31. 14 Jan, 2011 1 commit
  32. 20 Dec, 2010 1 commit
  33. 22 Dec, 2009 1 commit