April 2008 - cabal-devel

[Hackage] #258: case confusion - cabal vs Cabal
by Hackage 23 Jun '08

23 Jun '08

#258: case confusion - cabal vs Cabal ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- The darcs repo for Cabal is at darcs.haskell.org:/home/darcs/cabal yet it contains a file Cabal.cabal, which indeed claims that the name of the package is Cabal. This confusion of letter case is causing problems for me. Can we agree that Cabal is capitalised, and rename the repo dir? That seems like the simplest way to achieve consistency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/258> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #265: Cabal field stability not useful
by Hackage 22 Jun '08

22 Jun '08

#265: Cabal field stability not useful ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- As it stands, the 'stability:' field isn't very useful. Hardly anyone uses it, and even if someone does, it does minimal good, since it's just an arbitrary string. I propose it be changed into an enumerated type, like license: is. That way we could do things like have cabal-install warn when installing unstable, add view filters to Hackage, and so on. This is all stuff that'd be pretty ad-hoc if done on whatever strings package authors were writing. Now, what should the entries be? Ideally, we'd like to be able to say a couple things. We'd like to say that a release is Stable, or Unstable. For example, HaXml's most recent package on Hackage is Unstable, and that's why Goerzen's Hpodder uses an older, Stable, version of HaXml. But we'd also like to express not just stability, but feature-completeness - Alpha, Beta, Release. It's perfectly sensible to have a piece of software which is a Stable Alpha; early XMonads were very stable (I was using it from the first public repo patches, and it only ever crashed a handful of times, less than StumpWM). And equally I'd suggest you could have Unstable Betas. Most cabal files I've seen using stability: seem to use 'Stable', 'Unstable', 'Experimental', 'Alpha', or 'Beta'. (Although GTK2HS seems to be using 'Stability: provisional'). So perhaps one could make the stability field accept 0-2 entries: one from Stable/Unstable, and one from Experimental/Alpha/Beta/Release. -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/265> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #187: Paths_pkgname module is hard to use in a library
by Hackage 12 Jun '08

12 Jun '08

#187: Paths_pkgname module is hard to use in a library ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.1 Platform: Linux | ------------------------------+--------------------------------------------- Most users of the auto-generated {{{Paths_pkgname}}} module are programs. With GHC at least they can get away with not specifying the {{{Paths_pkgname}}} in the {{{Other-Modules}}} field. Get away with in the sense that it does not lead to linker errors because {{{ghc --make}}} does dependency chasing and links in all the necessary .o files. However for a library you must specify every module in {{{Exposed- Modules}}} or {{{Other-Modules}}} or one does get linker errors when you try to use the packages. That's because the missing module's .o files will not have been included in the library .a archive. See bug #128. So for a library one must specify {{{Other-Modules: Paths_pkgname}}} but then of course Cabal cannot find that module since it is not in the normal source directories but in {{{dist/build/autogen}}}. So people have to hack around it by adding {{{dist/build/autogen}}} to the {{{Hs-Source-Dirs}}} field. Obviously that's rather unsatisfactory. Probably the right solution is for Cabal to automatically add that directory to the end of the source dir search path. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/187> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #230: setup haddock ignores LANGUAGE CPP pragma
by Hackage 09 Jun '08

09 Jun '08

#230: setup haddock ignores LANGUAGE CPP pragma ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | 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: | ----------------------------------+----------------------------------------- `setup haddock` preprocesses sources with cpp if `CPP` is included in the `extensions` field, but not if a source file starts with {{{ {-# LANGUAGE CPP #-} }}} This is confusing, because that works with `setup build`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/230> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

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

09 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 09 Jun '08

09 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 09 Jun '08

09 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 09 Jun '08

09 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

[Hackage] #196: ability to specify custom args to haddock
by Hackage 26 May '08

26 May '08

#196: ability to specify custom args to haddock ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | ---------------------+------------------------------------------------------ From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293523 {{{ The ability to specify custom args to haddock, which is necessary to do things such as build docs that encompass parts of other packages }}} We can pass extra options to any program via the generic configure --$PROG-options= mechanism however for haddock this is not very useful since we also have to call haddock for another purpose and passing extra options there causes problems. Since the debian bug was filed there are several more feature of the haddock command, perhaps they solve the problem. If not, perhaps the problem could be explained further. What problem are we trying to solve here that would require passing extra options to haddock, and what extra options would one use? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/196> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #270: Build executables that can be run "in-place"
by Hackage 21 May '08

21 May '08

#270: Build executables that can be run "in-place" ----------------------------+----------------------------------------------- Reporter: waern | 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: | ----------------------------+----------------------------------------------- It would be nice if Cabal could build executables that could be told where to get their data files (etc), instead of always hard-wiring them to the installation dirs. Perhaps an environmental variable could be used to specify where the data files are. This would enable us to run applications "in-place", i.e. from the source directory directly, which would be useful for test suites, for example. David -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/270> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2