- cabal-devel - Haskell.org

patch applied (cabal): Split ghc's build action into buildLib and buildExe
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 11:32:50 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Split ghc's build action into buildLib and buildExe M ./Distribution/Simple/Build.hs -2 +3 M ./Distribution/Simple/GHC.hs -196 +200 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527183250-adfee-9540aef8…

1 0

patch applied (cabal): Remove unused ghc-only executable wrapper feature
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 11:32:45 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Remove unused ghc-only executable wrapper feature Some kind of shell script wrapper feature might be useful, but we should design it properly. M ./Distribution/Simple.hs -2 M ./Distribution/Simple/Build.hs -2 +2 M ./Distribution/Simple/GHC.hs -32 +3 M ./Distribution/Simple/Install.hs -14 +5 M ./Distribution/Simple/LHC.hs -32 +3 M ./Distribution/Simple/Setup.hs -18 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527183245-adfee-73f5fbfb…

1 0

patch applied (cabal): Fixup .cabal file with the removed modules and files
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 11:23:44 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Fixup .cabal file with the removed modules and files M ./Cabal.cabal -3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527182344-adfee-8ba12a9d…

1 0

patch applied (cabal): Fix warnings about unused definitions and imports
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 10:52:53 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Fix warnings about unused definitions and imports M ./Distribution/Simple/LHC.hs -11 +4 M ./Distribution/Simple/Register.hs -2 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527175253-adfee-2f658975…

1 0

patch applied (cabal): Remove the makefile generation feature
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 10:50:02 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Remove the makefile generation feature It was an ugly hack and ghc no longer uses it. M ./Distribution/Simple.hs -19 +1 M ./Distribution/Simple/Build.hs -23 +1 M ./Distribution/Simple/GHC.hs -128 +5 R ./Distribution/Simple/GHC/Makefile.hs R ./Distribution/Simple/GHC/Makefile.in R ./Distribution/Simple/GHC/mkGHCMakefile.sh M ./Distribution/Simple/LHC.hs -127 +2 M ./Distribution/Simple/Setup.hs -53 M ./Distribution/Simple/UserHooks.hs -12 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527175002-adfee-635148bb…

1 0

patch applied (cabal): Add new ComponentLocalBuildInfo
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 10:44:18 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Add new ComponentLocalBuildInfo We want to have each component have it's own dependencies, rather than using the union of deps of the whole package. M ./Distribution/Simple/Configure.hs -2 +6 M ./Distribution/Simple/LocalBuildInfo.hs -1 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527174418-adfee-1abacde0…

1 0

patch applied (cabal): Ticket #89 part 2: Dependency-related test cases and a simple test harness
by Duncan Coutts 27 May '09

27 May '09

Tue May 26 06:35:09 PDT 2009 rubbernecking.trumpet.stephen(a)blacksapphire.com * Ticket #89 part 2: Dependency-related test cases and a simple test harness Ignore-this: 830dd56363c34d8edff65314cd8ccb2 The purpose of these tests is mostly to pin down some existing behaviour to ensure it doesn't get broken by the ticket #89 changes. A ./tests/PackageTests/ A ./tests/PackageTests/BuildDeps/ A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive1/ A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive1/Check.hs A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive1/GlobalBuildDepsNotAdditive1.cabal A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive1/MyLibrary.hs A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive1/Setup.hs A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive2/ A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive2/Check.hs A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive2/GlobalBuildDepsNotAdditive2.cabal A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive2/Setup.hs A ./tests/PackageTests/BuildDeps/GlobalBuildDepsNotAdditive2/lemon.hs A ./tests/PackageTests/BuildDeps/InternalLibrary0/ A ./tests/PackageTests/BuildDeps/InternalLibrary0/Check.hs A ./tests/PackageTests/BuildDeps/InternalLibrary0/MyLibrary.hs A ./tests/PackageTests/BuildDeps/InternalLibrary0/Setup.hs A ./tests/PackageTests/BuildDeps/InternalLibrary0/my.cabal A ./tests/PackageTests/BuildDeps/InternalLibrary0/programs/ A ./tests/PackageTests/BuildDeps/InternalLibrary0/programs/lemon.hs A ./tests/PackageTests/BuildDeps/SameDepsAllRound/ A ./tests/PackageTests/BuildDeps/SameDepsAllRound/Check.hs A ./tests/PackageTests/BuildDeps/SameDepsAllRound/MyLibrary.hs A ./tests/PackageTests/BuildDeps/SameDepsAllRound/SameDepsAllRound.cabal A ./tests/PackageTests/BuildDeps/SameDepsAllRound/Setup.hs A ./tests/PackageTests/BuildDeps/SameDepsAllRound/lemon.hs A ./tests/PackageTests/BuildDeps/SameDepsAllRound/pineapple.hs A ./tests/PackageTests/PackageTester.hs A ./tests/Setup.hs A ./tests/suite.cabal A ./tests/suite.hs View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090526133509-77ee1-93331a3b…

1 0

patch applied (cabal): Ticket #89 part 1: add targetBuildDepends field to PackageDescription's target-specific BuildInfos
by Duncan Coutts 27 May '09

27 May '09

Tue May 26 06:37:29 PDT 2009 rubbernecking.trumpet.stephen(a)blacksapphire.com * Ticket #89 part 1: add targetBuildDepends field to PackageDescription's target-specific BuildInfos Ignore-this: 96572adfad12ef64a51dce2f7c5f738 This provides dependencies specifically for each library and executable target. buildDepends is calculated as the union of the individual targetBuildDepends, giving a result that's exactly equivalent to the old behaviour. M ./Distribution/PackageDescription.hs -3 +6 M ./Distribution/PackageDescription/Configuration.hs -38 +68 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090526133729-77ee1-b593f8af…

1 0

haddock-2.3.0 literate comments discarded from .lhs input
by Alistair Bayley 27 May '09

27 May '09

I have this test case for Haddock (2.3.0): -------------------------------------------------- | Module : Test.Haddock Copyright : (c) 2009 Alistair Bayley License : BSD-style Maintainer : alistair(a)abayley.org Stability : stable Portability : portable Test case for Haddock. > module Test.Haddock > ( > -- $named_block > Fail(..) > ) > where > data Fail = Fail | Succeed $named_block This is some hadock documentation. -------------------------------------------------- This fails with: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' If I manually unlit, then Haddock is happy: -------------------------------------------------- -- | -- Module : Test.Haddock2 -- Copyright : (c) 2009 Alistair Bayley -- License : BSD-style -- Maintainer : alistair(a)abayley.org -- Stability : stable -- Portability : portable -- -- Test case for Haddock. module Test.Haddock2 ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed -- $named_block -- -- This is some hadock documentation. -------------------------------------------------- so it looks as though it's discarding the literate comments. Is this intended? I was under the impression that because it used the ghc parser, it could now properly handle .lhs input. Ona related note, we have a nice unlitter in cabal that would preserve these comments before invoking haddock. Is this still used with haddock2, or does it now assume haddock2 will do the right thing? Alistair

5 27

Working on a fix for ticket #89
by Stephen Blackheath [to cabal-devel] 25 May '09

25 May '09

All, I'm working on a fix for ticket #89 (http://hackage.haskell.org/trac/hackage/ticket/89) and I have a specific question for the list: ---- If I do this... build-depends: base Library build-depends: bytestring ...then when the library compiles, it will fail to find the Prelude (i.e. -package base doesn't get passed to ghc). Is there a reason why the global 'build-depends' doesn't add to all targets (i.e. all exes & libs)? That's what I would expect it to do, but that might be just me. Or more to the point, should this be fixed? ---- The code changes I'm working on also fix a couple of other things, so this is the complete list: - Ticket #89: Make it so the executable can depend on the library defined in the same package. If hs-source-dirs is used, you can avoid it compiling the .hs files multiple times. - Make it so build-depends: defined in a Library or Executable block affects only the build of those components, not all components as currently happens. For avoidance of package breakage, this behaviour only happens if you specify cabal-version: >= 1.7 (that is, versions less than 1.7 are entirely excluded). - Make a really simple unit test harness using the test-framework package, and add some test cases for the new behaviour. The idea is that we can gradually integrate existing tests (hunit & quickcheck) into it. - Make UnitTests compile (though hardly any of the tests pass). This patch is not yet tidy enough to submit, but it is complete enough to actually work for GHC. I would welcome any comments. Here it is (against HEAD): http://upcycle.it/~blackh/cabal/cabal-ticket-89-v3.patch Steve

2 5