May 2008 - cabal-devel

patch applied (cabal): Revert one change of (.) to fmap. It was not necessary and broke nhc98.
by Duncan Coutts 01 May '08

01 May '08

Thu May 1 03:46:20 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Revert one change of (.) to fmap. It was not necessary and broke nhc98. The other one was needed as we changed a type from Bool to Maybe Bool. M ./Distribution/Simple/Command.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501104620-adfee-b0c0ab88…

1 0

installing all of hackage
by Duncan Coutts 01 May '08

01 May '08

All, We're getting nearer to being able to use cabal-install to install all of hackage for us. :-) I did a run this evening: $ cabal install -O0 $(cat pkgs) which is a list of 485 packages. I had to prune this list manually to eliminate the ones that have unsatisfiable dependencies (about 10). I hope to add a flag to get cabal-install to do that automatically, and where we do not use that flag, to produce better error messages saying *which* packages have the unsatisfiable dependencies. So I now have 329 library packages installed. It makes me notice this issue rather acutely: http://hackage.haskell.org/trac/ghc/ticket/2089 "reading the package db is slow" In fact this would be a really big problem for doing our own make-like system where we invoke ghc once for each module. Where at the moment it takes 1 second per library/executable, it'd take one second per module. It would in fact mean that reading the package database would take more time than compilation since compilation zips through at less than one second per module on average with -O0. I've also got a list of 163 install failures. Unfortunately we do not get logs of the failing packages, just a summary like: GuiTV-0.4 depends on wxcore-0.10.3 which failed to install. xtc-1.0 depends on wxcore-0.10.3 which failed to install. phooey-2.0 depends on wxcore-0.10.3 which failed to install. GenI-0.16.1 depends on wxcore-0.10.3 which failed to install. wx-0.10.3 depends on wxcore-0.10.3 which failed to install. AutoForms-0.4.0 depends on wxcore-0.10.3 which failed to install. wxcore-0.10.3 failed during the configure step. The exception was: exit: ExitFailure 2 Still, it's progress I feel. I've also added a flag to let us choose which version of the Cabal lib to use when building packages. This should make it possible to compare building everything with Cabal-1.2 and 1.4 for example. Duncan BTW, if you're wondering about the discrepancy in package numbers, it's because I had some packages installed already, some of which were not from hackage. Some of the packages I installed were binaries for which we do not track the installed state. Also, since some packages were already installed, cabal-install did not re-install them. So I don't know how many did actually install successfully, only how many failed.

1 0

hasLibs and hasExes honest reporting?
by Yaakov Nemoy 01 May '08

01 May '08

Hi List, First off, I want to say hi, as this is my first post. I'm trying to get some badly needed updates to cabal-rpm, so we can get more Haskell packages into Fedora. All of the following is with Cabal 1.2.3.0 and GHC 6.8.2 as packaged in Fedora 8. In the module Distribution.PackageDescription, there are four functions, hasExes, and hasLibs, as well as libModules and exeModules. These functions claim to do the obvious for a PackageDescription. The only problem I'm having is with packages like xmonad, which have both Executables and Libraries. In the case of xmobar, hasLibs returns False, and an empty list for libModules, but True and a list for hasExes and exeModules respectively. In the case of xmonad-contrib, the opposite is true, that is there are no Executables at all, but a bucket load of Libraries. In the case of xmonad, hasLibs returns True. but returns a nonempty list. hasExes returns True, and with the same nonempty list. I would expect the lists to be the same, as all the Modules listed therein are needed to compile the executable, and also to be linked with the user supplied config file. The only problem I see is with hasLibs itself. I heard something a while back that xmonad needs to be compiled twice, because this setup is considered an edge case in Cabal. Because xmonad is the reason why I'm working on getting Haskell packages into Fedora, I'm not sure I want to think of it that way. Is this a bug, or just a 'feature' I need to watch out for? Cheers, Yaakov Nemoy

3 5