This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 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
  2. 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
  3. 24 Apr, 2014 1 commit
  4. 23 Apr, 2014 1 commit
  5. 14 Apr, 2014 1 commit
  6. 02 Feb, 2014 1 commit
  7. 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
  8. 21 Aug, 2013 1 commit
  9. 18 Mar, 2013 1 commit
  10. 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
  11. 03 Nov, 2012 3 commits
  12. 23 Aug, 2012 1 commit
  13. 23 Oct, 2011 1 commit
  14. 11 Oct, 2011 2 commits
  15. 25 Aug, 2011 1 commit
  16. 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
  17. 19 Jun, 2011 1 commit
  18. 24 May, 2011 1 commit
  19. 18 May, 2011 1 commit
    • Duncan Coutts's avatar
      Do a sanity check on the HookedBuildInfo · 91a6d9fb
      Duncan Coutts authored
      Fixes ticket #844. Previously the function that merged the HookedBuildInfo
      into the PackageDescription would add a library section even if none
      previously existed.
      
      Now we generate an error message if the HookedBuildInfo contains info
      for non-existant components (libs/exes), e.g:
      
      Setup: The buildinfo contains info for a library, but the package does not
      have a library.
      91a6d9fb
  20. 08 May, 2011 1 commit
  21. 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
  22. 10 Jan, 2011 1 commit
    • ttuegel's avatar
      Tracking enabled/disabled TestSuites in PackageDescription. · f0a2d5e3
      ttuegel authored
      This patch adds the 'testEnabled' field to TestSuite. It's 
      undesirable to track build status information in the static package 
      description, but there is no better solution at this time. This 
      patch has the side-effect of fixing several TODOs in 
      Distribution.Simple.Configure.
      f0a2d5e3
  23. 18 Oct, 2010 1 commit
    • Duncan Coutts's avatar
      Add new language and extensions fields (internal data structures) · 7a8c60d0
      Duncan Coutts authored
      New fields default-language and other-languages for specifying the
      base languages for the package, e.g. Haskell98, Haskell2010
      New fields default-extensions and other-extensions for the language
      extensions. Separate from the old extensions field.
      The separation lets us express the difference between declaring to
      the outside world that a package uses certain languages or extensions
      and whether certain languages or extensions should be applied to
      all modules in the package component.
      7a8c60d0
  24. 13 Oct, 2010 2 commits
    • Duncan Coutts's avatar
    • 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
  25. 10 Oct, 2010 2 commits
  26. 03 Aug, 2010 1 commit
  27. 13 Jul, 2010 1 commit
    • ttuegel's avatar
      Removed duplicate code for test suite interface version checks · 70e2478b
      ttuegel authored
      Ticket #215 (Overhaul support for packages' tests).  Duplicate code for checking
      the test suite interface version was replaced with a single function
      'testVersion1 :: Version -> Bool' exported from Distribution.PackageDescription.
      70e2478b
  28. 25 Aug, 2010 1 commit
    • adept's avatar
      Auto-reconfiguration when .cabal is newer than setup-config · 549a6985
      adept authored
      This patch adds "ConfigFlags" to the "LocalBuildInfo" and reuses them to
      perform "configureAction" when .cabal file is changed. This has
      the same effect as re-running "configure" with the most recent used
      set of options, which should be the sensible thing to do.
      
      Closes #294, #477, #309 and #518.
      549a6985
  29. 09 Jun, 2010 1 commit
    • ttuegel's avatar
      Parsing TestSuite through intermediate data structure · c6aeef43
      ttuegel authored
      Ticket #215 (Overhaul support for packages' tests).  By parsing the test suite
      stanza through an intermediate data structure, we can isolate errors due to
      missing required fields in the parsing stage and avoid having error handlers
      througout the code.
      c6aeef43
  30. 08 Jun, 2010 1 commit
  31. 07 Jun, 2010 1 commit
  32. 03 Jun, 2010 1 commit
  33. 02 Jun, 2010 1 commit
  34. 01 Jun, 2010 1 commit
    • ttuegel's avatar
      Using more specific error messages for unsupported test types · f77f9334
      ttuegel authored
      Ticket #215 (Overhaul support for packages' tests). Replaced generic error
      message about unsupported test types with specific error messages for each
      stage of the build/test process. This required changing the type of 'withTest'
      to better match 'withExe' and 'withLib'.
      f77f9334
  35. 26 May, 2010 1 commit
    • ttuegel's avatar
      Parse Test stanzas · 4d137d0c
      ttuegel authored
      Ticket #215 (Overhaul support for packages' tests). Test
      stanzas are parsed into the GenericPackageDescription and
      PackageDescription data structures.
      4d137d0c