March 2007 - cabal-devel

Why is there a cabal file at all?
by Marc Weber 12 Mar '07

12 Mar '07

Sorry for this stupid question put there must be reasons I don't know. I've been thinking a lot about packaging/ dependency handling etc the last days. Haskell is one of the most typesafe and expressive languages, right? Now we need a haskell compiler/ interpreter to run Setup.hs. So why not combine both and use some kind of cabal combinator library? I'll try to implement a prototype although knowing there are lots of people knowing how to do this better. module Setup where import CabalBuildProposal helloWorld = haskell-executable $ do setName "helloworld" sourceDir "src" $ mainIs "HelloWorld.hs" addDependencies = case stringOption "pretty_print_lib" of "A" : [LibVersionRange "A" "1.0 - 2.0"] "B" : [LibVersionRange "B" "1.0 - 2.0"] package = do setAuthor = "Marc Weber" addAtom helloWorld preprocess = defaultHaskellPreprocess build = preprocess >>= defaultHaskellBuild rpm = build >>= defaultRPM install = defaultHaskellInstall haddock = defaultHaddock targets = [ ("preprocessOnly", preprocess) , ("build", build ) , ("install", build >>= install) , ("rpm", rpm ) , ("haddock", preprocess >>= haddock) ] main = do handle package targets using preprocessors might be done in this way: addExposedModules $ map preprocessByCPP $ modulesByRegex "src/**/*.hs" I think you get the idea why this approach might be much more powerful? The package mantainers of ght2hs and wkhaskell have both trouble makeing their project work with cabal.. So why do we limit ourself using cabal files like the existing ones? I think you've noticed the line addDependencies = case stringOption "pretty_print_lib" of This should use the correct dependency if the option has already been set by cmdline or config file else ask the user or choose the first but noticing the user by printing a message like this: unset option "pretty_print_lib", defaulting to "A" preprocess should be passed all configuration options and return a list of source files, build should get the list of source file and return a list of executables which are installed by install straightforward, isn't it? Thus the right build/ install whatsoever step would be choosen not by defining hooks but by the haskell type system. This way the packaging system user can plug in his own implementation everywhere. Any ideas, comments? Anyone out there who wants to join and help implementing this idea? Marc

9 29

branches and merging
by Simon Marlow 11 Mar '07

11 Mar '07

Cabal has the following branches: HEAD, in darcs.haskell.org:/cabal, used by GHC HEAD 1.1.6, in darcs.haskell.org/cabal-branches/cabal-1.1.6 GHC 6.6 branch, in darcs.haskell.org/ghc-6.6/packages/Cabal The official 1.1.6 is diverging from GHC's 6.6 version. We should merge the two - Duncan would you like to take a look and see if you can pull from GHC's branch into 1.1.6, and then we can use 1.1.6 in GHC 6.6? Also I just noticed that Ross's patch Mon Nov 20 09:25:26 GMT 2006 Ross Paterson <ross(a)soi.city.ac.uk> * trim trailing spaces (including CRs) from all input lines fixes #117 http://hackage.haskell.org/trac/hackage/ticket/117, and could easily be merged into 1.1.6. Cheers, Simon

2 1

darcs patch: Add preliminary support for haddock-ghc (and 9 more)
by davve＠dtek.chalmers.se 09 Mar '07

09 Mar '07

Fri Sep 15 21:29:49 CEST 2006 davve(a)dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Dec 29 20:54:39 CET 2006 davve(a)dtek.chalmers.se * Make sure haddock-ghc really creates the output dir Sun Dec 31 00:21:16 CET 2006 davve(a)dtek.chalmers.se * Add compilerPath to Paths_<pkg> Fri Jan 5 22:22:24 CET 2007 davve(a)dtek.chalmers.se * Add -D__HADDOCK__ to haddock-ghc Sat Jan 6 02:44:20 CET 2007 davve(a)dtek.chalmers.se * Generate GHC arguments usable for haddock-ghc Sat Jan 6 02:48:01 CET 2007 davve(a)dtek.chalmers.se * Use -g option to send GHC arguments to haddock-ghc Thu Jan 18 22:55:20 CET 2007 davve(a)dtek.chalmers.se * Don't send -cpp to haddock-ghc Mon Feb 5 00:49:25 CET 2007 davve(a)dtek.chalmers.se * Synch Haddock-GHC changes with recent changes to Cabal Mon Mar 5 17:53:42 CET 2007 davve(a)dtek.chalmers.se * Solve conflict Mon Mar 5 20:00:45 CET 2007 davve(a)dtek.chalmers.se * Use only one haddock command This patch merges the haddock-ghc and haddock commands, treating the "haddock" executable as haddock-ghc if the version is >= 2.0.

3 2

darcs patch: Add preliminary support for haddock-ghc (and 10 more)
by davve＠dtek.chalmers.se 09 Mar '07

09 Mar '07

Fri Sep 15 21:29:49 CEST 2006 davve(a)dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Dec 29 20:54:39 CET 2006 davve(a)dtek.chalmers.se * Make sure haddock-ghc really creates the output dir Sun Dec 31 00:21:16 CET 2006 davve(a)dtek.chalmers.se * Add compilerPath to Paths_<pkg> Fri Jan 5 22:22:24 CET 2007 davve(a)dtek.chalmers.se * Add -D__HADDOCK__ to haddock-ghc Sat Jan 6 02:44:20 CET 2007 davve(a)dtek.chalmers.se * Generate GHC arguments usable for haddock-ghc Sat Jan 6 02:48:01 CET 2007 davve(a)dtek.chalmers.se * Use -g option to send GHC arguments to haddock-ghc Thu Jan 18 22:55:20 CET 2007 davve(a)dtek.chalmers.se * Don't send -cpp to haddock-ghc Mon Feb 5 00:49:25 CET 2007 davve(a)dtek.chalmers.se * Synch Haddock-GHC changes with recent changes to Cabal Mon Mar 5 17:53:42 CET 2007 davve(a)dtek.chalmers.se * Solve conflict Mon Mar 5 20:00:45 CET 2007 davve(a)dtek.chalmers.se * Use only one haddock command This patch merges the haddock-ghc and haddock commands, treating the "haddock" executable as haddock-ghc if the version is >= 2.0. Fri Mar 9 14:08:37 CET 2007 davve(a)dtek.chalmers.se * Send GHC libdir to haddock-ghc and synch with recent changes

1 0

Cabal and rpm packageing
by Olivier Thauvin 08 Mar '07

08 Mar '07

Hi, I am a mandriva contributor and the current maintainer of ghc and hugs. haksell modules currently give headhash to find the best way to package it. - we need to register it after installation, the order should be preserved - they have dependencies between them it seems (ie to use missingh I need also to have filepath and hslogger installed). - each package have to be build with each compiler. Feel free to Rpm is not able really to preserve a installation order (partially because bug inside rpmlib). For mandriva, I started some work to make haskell packaging easier. For now this concern only ghc (more popular, and hugs is not working properly: ERROR "/usr/share/hugs/packages/base/Text/ParserCombinators/ReadP.hs":156 - Syntax error in type expression (unexpected `.'), error not happening is using ghc on this file... another topic). First step is to create a set of macros for makor cabal build step, aka configure, build, haddock, test, copy. I provide also a macro to setup trigger and so (un)register module on ghc changes. The second is to automatically find dependencies and report it to rpm. To do that I create a small programme set around cabal: [olivier@andromede haskell-CabalRpmDeps]$ runhaskell Setup.hs configure [...] [olivier@andromede haskell-CabalRpmDeps]$ dist/build/cabalrpmprov/cabalrpmprov haskell(CabalRpmDeps) = 0.0.1 [...] [olivier@andromede haskell-CabalRpmDeps]$ dist/build/cabalrpmreq/cabalrpmreq haskell(unix) = 1.0 haskell(haskell98) = 1.0 haskell(base) = 2.0 haskell(Cabal) = 1.1.6 The haskell(...) names are wanted to match rpm dependencies scheme. The bad things is useally dependencies are find using files list from each packages. But I didn't any solution to query .hi files, and I am not sure they contains information I need. So here I use the the cabal library to query the module from files in builddir, but it doesn't matter, the cabal package cannot be split. Now I have to write scripts around those progs and checking everything works fine. The darcs repos is accessible there (using darcsweb, the page the url to fetch the repos): http://nanardon.zarb.org/darcsweb/darcsweb.cgi?r=haskell-CabalRpmDeps;a=sum… Comments welcome.

2 1

Re: How to debug a segfault.
by Duncan Coutts 01 Mar '07

01 Mar '07

On Wed, 2007-02-28 at 09:32 -0800, David Brown wrote: > However, what I missed is that the hsc2hs target files are placed > alongside the source, not in the dist directory. I had been building > zlib on x86 using the hs generated on an amd64 machine. The offsets > in the structures were wrong. Ohh, nasty. > How difficult would it be to have Cabal store the target files in the > 'dist' directory with everything else? This also makes revision > control a little more challenging, because I have to hand-pick a few > select .hs files to ignore, since the rest of my code is sitting right > next to them. That would be good. I don't suppose it's too hard, after all we put other generated modules in dist (the paths module). We then just have to add more -i search dirs. I'd be happy to review cabal patches along these lines. [ On the plus side, I'm glad it wasn't a bug in my zlib binding :-) ] Duncan

1 0