February 2008 - cabal-devel

[Hackage] #198: cabal install foo should upgrade foo if there's a newer version
by Hackage 12 Aug '08

12 Aug '08

#198: cabal install foo should upgrade foo if there's a newer version ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/198> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #175: cabal-install needs a new package dependency resolution algorithm
by Hackage 12 Aug '08

12 Aug '08

#175: cabal-install needs a new package dependency resolution algorithm ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------+----------------------------------------------- The current package dependency algorithm is pretty simple. It's main failing is that it cannot backtrack if it finds the solution is impossible. What we would like is a new dependency resolution algorithm that can backtrack. We would also like to be able to configure policy issues separately, perhaps as a parameter. It may also be handy to let users or the system add extra version constraints. The input is the set of available packages and the output is a list of packages to install, and the assignment of configuration flags to use for each one. As for the policy input, this might take the form of a function that picks between possible dependencies in a slot, this could then allow us to make choices like preferring installed packages over the latest available package version, or vica versa. See also symptoms of the existing system: * bug #168 -- lack of configurable policy * bug #174 -- lack of backtracking -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/175> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #213: allow wildcards in data-files or extra-source-files?
by Hackage 29 Jul '08

29 Jul '08

#213: allow wildcards in data-files or extra-source-files? ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Some packages end up with very very long fields for data-files or extra- source-files. Is this a problem? Should we allow some kind of globing to make it a bit less verbose? {{{ extra-source-files: cbits/*.h c-sources: cbits/*.c }}} On the other hand, there is a danger with globing that you pick up too many files. Perhaps we can counter that by making the globing rather restrictive, like no subdirectory recursion, and only allowing *'s in the final directory component, so no {{{data/*/*}}} patterns. Is there a sweet spot that allows conciseness without including too much accidentally? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/213> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #232: implement extended syntax for package version ranges
by Hackage 29 Jul '08

29 Jul '08

#232: implement extended syntax for package version ranges ----------------------------+----------------------------------------------- Reporter: duncan | Owner: nominolo Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Revised proposal: http://www.haskell.org/pipermail/cabal- devel/2008-January/001786.html Reproduced here: In order to make it easy for package package authors to describe correct and robust dependencies we (Duncan Coutts and I) propose the following syntactical extension to version range specifications in package files. == Wildcards == {{{ ~ 1.2.* ~~> >= 1.2 && < 1.3 }}} in general {{{ ~ x.y.* ~~> >= x.y && < x.(y+1) }}} The "~" operator should be read as "in the range of". Another option would have been "-", but this is used to specify exact versions in other parts of the Cabal infrastructure , e.g., "cabal install xmonad-0.5". This is the most common specification of package dependencies. The assumption is that changes in the last version number indicate only backwards compatible changes, as is suggested in the new package versioning policy [1]. The use of "*" matches the common usage as a wildcard character. == Upward Ranges == {{{ ~ 1.2.1+ ~~> >= 1.2.1 && < 1.3 }}} in general {{{ ~ x.y.z+ ~~> >= x.y.z && < x.(y+1) }}} The idea here is that sometimes packages need a certain patch level or, as in Cabal's case, a stable release and possible further bugfixes. In those cases the wildcard notation is too liberal, however the explicit range description would be too noisy (and possibly error prone). (Also, using "+" instead of "*" serves as better visual distinction.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/232> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[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