- cabal-devel - Haskell.org

[Hackage] #470: bad error message when a package transtively depends on two versions of the same one
by Hackage 03 Mar '09

03 Mar '09

#470: bad error message when a package transtively depends on two versions of the same one ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The following error appears like nonsense: {{{ cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1 }}} It actually means that there's some package ghc depends on that now is built against the newer process. It should tell the name of the other package(s), too. This is made worse by user-installed packages of the same version shadowing global ones, in this case there is no real error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/470> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #238: haddock2 is not passed -D__HADDOCK__ or cpp-options
by Hackage 03 Mar '09

03 Mar '09

#238: haddock2 is not passed -D__HADDOCK__ or cpp-options ----------------------------------+----------------------------------------- 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: | ----------------------------------+----------------------------------------- With haddock-1, Cabal invokes cpp, passing it ARCH and OS defines, -D__HADDOCK__ and the contents of cpp-options. However haddock-2 invokes cpp itself via the GHC API, which passes this cpp the ARCH and OS defines, but it doesn't get the others. It might also be a good idea to give __HADDOCK__ a numeric value, because GHC extensions need not be hidden from the new one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/238> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #189: Handle framework paths (-F) in Cabal
by Hackage 03 Mar '09

03 Mar '09

#189: Handle framework paths (-F) in Cabal --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Mac OS | --------------------------+------------------------------------------------- There's been some discussion on the GHC trac ([http://hackage.haskell.org/trac/ghc/ticket/1931 1931], [http://hackage.haskell.org/trac/ghc/ticket/1798 1798], [http://hackage.haskell.org/trac/ghc/ticket/1395 1395]) about adding framework search paths (gcc's `-F` flag, and ghc's `-framework-path` flag). Currently Cabal handles `-framework`, but not `-framework-path`. I propose the following behavior for Cabal: 1. Add a `framework-path:` field which will pass `-framework-path` to `ghc` and `-F` to `gcc`, `hsc2hs`, et. al. 2. Always add `-F$HOME/Library/Frameworks` as an argument to the above programs (regardless of any `framework-path` entries). I believe `#1` to be uncontroversial. My reasoning for `#2` is the following: - `$HOME/Library/Frameworks` is the standard location to put frameworks if you do not have administrative access. - Without it, `readline.cabal` (e.g.) would need {{{ framework-path: /Users/judah/Library/Frameworks }}} which is not portable between machines. Finally, note that these flags only affect build behavior, not runtime loading of libraries (which searches `$HOME/Library/Frameworks` by default). See [http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks OSXFrameworks] for more info. -Judah -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/189> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 13

[Hackage] #206: cabal-install should be able to generate haddock docs
by Hackage 03 Mar '09

03 Mar '09

#206: cabal-install should be able to generate haddock docs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | 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 | ---------------------------------+------------------------------------------ It would be really cool if it could keep an index up to date as well. (I like to have offline docs for all installed packages, but it's a headache to keep current.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/206> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 16

Re: [Hackage] #42: make hugs, nhc, lhc and Cabal agree on installed package info
by Hackage 03 Mar '09

03 Mar '09

#42: make hugs, nhc, lhc and Cabal agree on installed package info ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ross(a)soi.city.ac.uk Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.2.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: normal => hard (< 1 day) * summary: implement hugs-pkg? => make hugs, nhc, lhc and Cabal agree on installed package info * milestone: => _|_ Comment: This isn't tht hard but needs changes in Hugs and a bit in Cabal and then testing and a new hugs release. The scheme with installed package info files should work for hugs, nhc and lhc. On the Cabal side of things the same implementation can be used for each. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/42#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

darcs patch: rewrite of Distribution.Simple.Haddock
by Andrea Vezzosi 02 Mar '09

02 Mar '09

Thu Feb 19 16:37:38 CET 2009 Andrea Vezzosi <sanzhiyan(a)gmail.com> * rewrite of Distribution.Simple.Haddock In addition to (hopefully) making clear what's going on we now do the additional preprocessing for all the versions of haddock (but not for hscolour) and we run cpp before moving the files.

2 3

[Hackage] #512: Use a proper exception for the 'die' utility function
by Hackage 02 Mar '09

02 Mar '09

#512: Use a proper exception for the 'die' utility function ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently the `die` function prints the error message to stderror and throws an exit with exception. This is not a good approach for library code. Instead it should throw an user error exception with the string message. A top level handler in `Distribution.Simple.main` or `cabal- install` should catch this, print it as before and throw an exit exception. See also #510 for an example of how this causes problems. The `readPackageDescription` ends up throwing the exit exception when it would be more helpful to clients for it to throw an ordinary exception containing the error message. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/512> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): use -D__HADDOCK__ only when preprocessing for haddock < 2
by Duncan Coutts 02 Mar '09

02 Mar '09

Sun Mar 1 17:51:37 PST 2009 Andrea Vezzosi <sanzhiyan(a)gmail.com> * use -D__HADDOCK__ only when preprocessing for haddock < 2 Ignore-this: d186a5dbebe6d7fdc64e6414493c6271 haddock-2.x doesn't define any additional macros. M ./Distribution/Simple/Haddock.hs -4 +7 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090302015137-cd449-2c7b00e8…

1 0

patch applied (cabal): Make die use an IOError that gets handled at the top level
by Duncan Coutts 02 Mar '09

02 Mar '09

Sun Mar 1 11:51:43 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Make die use an IOError that gets handled at the top level Rather than printing the error there and then and throwing an exit exception. The top handler now catches IOErrors and formats and prints them before throwing an exit exception. Fixes ticket #512. M ./Distribution/Simple.hs -2 +2 M ./Distribution/Simple/Utils.hs -10 +30 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090301195143-adfee-8f23fd09…

1 0

patch applied (cabal): rewrite of Distribution.Simple.Haddock
by Duncan Coutts 02 Mar '09

02 Mar '09

Thu Feb 19 07:37:38 PST 2009 Andrea Vezzosi <sanzhiyan(a)gmail.com> * rewrite of Distribution.Simple.Haddock Ignore-this: 5b465b2b0f5ee001caa0cb19355d6fce In addition to (hopefully) making clear what's going on we now do the additional preprocessing for all the versions of haddock (but not for hscolour) and we run cpp before moving the files. M ./Distribution/Simple/Haddock.hs -250 +393 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090219153738-cd449-ba14753e…

1 0