May 2008 - cabal-devel

[Hackage] #252: haddock document generation fails for executables when a preprocessors is needed
by Hackage 10 Jun '08

10 Jun '08

#252: haddock document generation fails for executables when a preprocessors is needed ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- I'm coming to think I'm the only one who tries to generate haddock documentation for non library packages...;) When running "haddock --executables" with a package that has a module which is using a file extension to call a preprocessor, Haddock.getModulePaths will die with: Setup.lhs: can't find source for module moduleName If I add a library stanza to the cabal file, the problem is solved. This issue affects HEAD only. I must confess I do not understand why this happens, and I'm puzzled. But I don't know the cabal source enough, so I'll leave this to the expert ones. Cheers, Andrea Rossato ps: maybe even the short summary could be edited to better describe the problem. An English native speaker could be quite helpful with this...:-) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/252> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #249: "haddock --hoogle" does not produce any effect
by Hackage 10 Jun '08

10 Jun '08

#249: "haddock --hoogle" does not produce any effect ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- When running runhaskell Setup.hs haddock --hoogle will produce nothing, whereas a dist/doc/html/pkgid.txt should be created. I'm running Cabal-1.2.3.0 with ghc-6.8.2 and Haddock-2.0.0.0 Cheers Andrea Rossato -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/249> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #250: 'haddock --executables" should dump the haddock interface too
by Hackage 10 Jun '08

10 Jun '08

#250: 'haddock --executables" should dump the haddock interface too ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- otherwise 'install' or 'copy --destdir=destdir' will fail with: Setup.lhs: dist/doc/html/pkgid/pkgid.haddock: copyFile: does not exist (No such file or directory) I tried to send a patch to the cabal-devel ML, but I'm not a subscriber, so I'm attaching the patch here. Cheers -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/250> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #248: Running "haddock --hyperlink-source" fails with a "requires Haddock version 0.8 or later" message
by Hackage 10 Jun '08

10 Jun '08

#248: Running "haddock --hyperlink-source" fails with a "requires Haddock version 0.8 or later" message ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Hello, when running something like: runhaskell Setup.lhs haddock --hyperlink-source --hscolour- css=/usr/local/share/hscolour-1.9/hscolour.css Cabal fails with: Setup.lhs: haddock --hyperlink-source requires Haddock version 0.8 or later This seems to be the involved code (from Distribution.Simple.Haddock (line 148): when (hsColour && not have_src_hyperlink_flags) $ die "haddock --hyperlink-source requires Haddock version 0.8 or later" Cabal 1.2.3.0 (with ghc-6.8.2) and Haddock 2.0.0.0. Cheers, Andrea Rossato -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/248> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Probably Cabal bug
by Krasimir Angelov 02 Jun '08

02 Jun '08

Hi, I have a package with one library and one executable. Something like this: name: ... version: ... library build-depends: base, array, containers, bytestring, random .... executable ... build-depends: base, array, containers, bytestring, filepath, directory, random, old-time, process, pretty Although I specified that the library depends only on few packages the installed package really depends on the union of packages for listed for the library and for the executable. I am using Cabal-1.2.3.0. Is this a known issue?

2 1

patch applied (cabal-branches/cabal-1.2): Bump version number to 1.2.4.0
by Ian Lynagh 31 May '08

31 May '08

Thu May 29 10:23:38 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Bump version number to 1.2.4.0 And update the changelog. There should be no incompatible API changes or incompatible behaviour changes. There are a number of compatible API extensions and behaviour fixes. In particular this gives us a limited amount of forward compatabilty with Cabal-1.4, ie there are things that work in 1.4 that would break with 1.2.3.0 but should work with 1.2.4.0. M ./Cabal.cabal -2 +2 M ./Makefile -2 +2 M ./changelog +14 M ./releaseNotes -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008052917…

1 0

patch applied (cabal-branches/cabal-1.2): Fix backport of 'Find original sources for main-is when creating sdist'
by Ian Lynagh 31 May '08

31 May '08

Thu May 29 10:07:15 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix backport of 'Find original sources for main-is when creating sdist' Required an extra util function. M ./Distribution/Simple/SrcDist.hs -2 +3 M ./Distribution/Simple/Utils.hs -7 +35 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008052917…

1 0

patch applied (cabal-branches/cabal-1.2): Find original sources for main-is when creating sdist
by Ian Lynagh 31 May '08

31 May '08

Thu Jan 31 03:49:09 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Find original sources for main-is when creating sdist Also add a package sanity check that main-is must specify a .hs or .lhs file. So the bahaviour is now that main-is specifies the main source file, even if that is generated by a pre-processor. This isn't really a change in behaviour since previously if you specified main-is: main.hsc then it would try to pass the .hsc file to ghc dirctly which would not work. For ticket #14 things were fixed to that it would look for main.hsc if you used main-is: main.hs an that file did not exist directy. This completes the other half, of actually being able to make a src distribution. So this should fix bug #217. Note that this still needs some work, we do not run platform-independent preprocessors and put the result into the tarball for main-is files. Generally, main-is has been the second class citizen compared to normal modules. We should try and refactor so both use the same code paths. M ./Distribution/PackageDescription.hs -4 +8 M ./Distribution/Simple/SrcDist.hs -1 +5 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008013111…

1 0

patch applied (cabal-branches/cabal-1.2): When multiple specifying list fields in the same section combine them
by Ian Lynagh 31 May '08

31 May '08

Wed Apr 23 13:15:19 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * When multiple specifying list fields in the same section combine them eg if you had: extensions: Foo extensions: Bar, Baz then previously we only ended up with [Bar, Baz]. Now we get them all. Only applies to list fields, for single fields the second value is taken and the first is silently discarded. This isn't good of course but the fix is harder since we're not in a context where we can report errors. Really we should just declare up front what kind of field it is and inherit the right behaviour automagically, either duplicates disallowed or allowed and combined with mappend. M ./Distribution/ParseUtils.hs -3 +7 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008042320…

1 0

patch applied (cabal-branches/cabal-1.2): We do not show the field value on a parse error so don't pretend we do.
by Ian Lynagh 31 May '08

31 May '08

Thu Mar 27 15:14:42 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * We do not show the field value on a parse error so don't pretend we do. Drop the trailing ": " on the error message. We could provide the field value but they're often multi-line and we cannot pin-point where the error is exactly. M ./Distribution/ParseUtils.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008032722…

1 0