February 2007 - cabal-devel

[Conal Elliott] Re: getting cabal to pass more info to haddock
by Isaac Jones 15 May '07

15 May '07

3 7

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

merge problem
by Ross Paterson 27 Feb '07

27 Feb '07

The HEAD version of Cabal contains a rather large patch called "Refactorings only", which inadvertantly fixed a bug: the 6.6 version rejects a Cabal file that contains unknown fields but no library. It would be handy if that bug could be fixed in the 6.6 version too. Would it be best to make a subset of the patch?

2 1

Added RPM generation capability to Cabal
by Bryan O'Sullivan 22 Feb '07

22 Feb '07

I spent a few hours over the past couple of days hacking on Cabal to add the ability to build RPM packages. You can fetch my darcs repository from here: darcs get --partial http://darcs.serpentine.com/cabal-rpm This new capability is easy to use. It adds a single new Cabal command, called rpm. runhaskell Setup.*hs rpm This generates a spec file, and builds source and binary RPMs. Here’s a quick example, of trying to build the Haskell XML-RPC library: ~/src/darcs/haxr $ runghc Setup.*hs rpm Source tarball created: dist/SOURCES/haxr-3000.0.0.tar.gz error: Failed build dependencies: HaXml-ghc66 >= 1.13 is needed by haxr-3000.0.0-1.i386 HaXml-ghc66 < 1.14 is needed by haxr-3000.0.0-1.i386 Setup.lhs: rpmbuild failed with status 1 The rpm command has converted the dependencies in the haxr.cabal file into build-time and runtime dependencies in the haxr.spec file that it generated, but rpmbuild can’t find the HaXml package. Having earlier built a HaXml package using the rpm command, I can install it with the system’s rpm command. # rpm -i haxml-ghc66-1.13.2-1.i386.rpm Reading package info from stdin ... done. Saving old package config file... done. Writing new package config file... done. The RPM’s post-install scriptlet informs GHC’s package manager about the package’s availability: # ghc-pkg list --simple | tr ' ' '\n' | grep -i haxml HaXml-1.13.2 Now if I try to build haxr again, it will succeed. By default, the rpm command builds both normal and profiling-enabled libraries. It also uses Haddock to generate library documentation. It’s possible to control these behaviours from the command line. The command also provides a --gen-spec option, which only generates a spec file. You can use this >spec file as a basis for crafting one of your own. I’ve used the rpm command to build about a third of the packages listed in the Hackage package database, with no problems.

7 9

#112: Documention error (should be easy to fix)
by Ross Paterson 21 Feb '07

21 Feb '07

The documentation is wrong, but what's actually happening is that "setup configure" takes a --with-compiler option, but changes that into a --with-hc option when calling configure. That's pretty gross, and I don't think anyone is using the --with-hc option: should we just change it to --with-compiler for simplicity?

1 0

Trac has me baffled
by Bryan O'Sullivan 21 Feb '07

21 Feb '07

I'd like to file a bug against Cabal, but I cannot for the life of me figure out how to create an account at http://hackage.haskell.org/trac/hackage/ If there is a "create an account" knob somewhere, I cannot see it. For the record, the bug is that the sdist command doesn't archive files listed in "install-includes" to a tarball. The result is that if you try to build a tree unpacked from sdist, it will fail. I've seen this with a few packages. <b

3 2

Re: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default)
by Duncan Coutts 19 Feb '07

19 Feb '07

On Sun, 2007-02-11 at 16:46 -0800, Ross Paterson wrote: > Sun Feb 11 16:45:13 PST 2007 Ross Paterson <ross(a)soi.city.ac.uk> > * add --enable-optimization/--disable-optimization config options (on by default) > > M ./Distribution/Setup.hs +9 > M ./Distribution/Simple/Configure.hs +1 > M ./Distribution/Simple/GHC.hs +1 > M ./Distribution/Simple/LocalBuildInfo.hs +1 > M ./doc/Cabal.xml +18 This is great (I kept meaning to get round to it!) but I'm not sure it should be on by default. Certainly it should be used by cabal-install since that is a user tool for installing a package, but developers use the Seyup.hs or cabal-setup tools directly and they will not want -O to be on by default I think. If they were building it to install then they'd use the other tool, so if they're using the dev tool then it's likely because they want to do some development work and so will want a shorter build time. (Similarly, profiling is off for Setup.hs/cabal-setup but perhaps should be on by default for cabal-install) Am I wrong? What do other people reckon? Duncan

4 4

[Conal Elliott] Re: Fwd: cabal-make almost ready
by Isaac Jones 13 Feb '07

13 Feb '07

1 0

darcs patch: Add preliminary support for haddock-ghc (and 7 more)
by davve＠dtek.chalmers.se 12 Feb '07

12 Feb '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

3 2

Dependencies/backwards compatibility in Hackage
by Sven Moritz Hallberg 05 Feb '07

05 Feb '07

Hi everyone, While trying out cabal-install today, I stumbled across the following: I wanted to install XmlRpc which depends on HaXml and works with HaXml-1.13.2. However, HaXml-1.17 which has also been uploaded to hackageDB changed an exposed module's name and XmlRpc doesn't work with it anymore. I'm wondering how to avoid such situations. I appears to me that expecting the maintainer of every package depending on HaXml to update their dependencies "after the fact" doesn't make sense because it leaves an arbitrarily long window where the package won't build straight out of hackageDB. Wouldn't it be sensible for the author of HaXml to specify in the .cabal file for version 1.17 whether it is backwards-compatible or not? I'd imagine a field like "compatible:" or something to name any older versions that this version is backwards-compatible to, e.g. name: base version: 2.0 compatible: 1.0 ... The field would default to "not backwards-compatible to anything" so it would fail safe in the case where it's not given. There would still be the possibility of the maintainer erroneously stating compatibility where there is none. For example, she could set the field at some point and forget to update it. There might be a clever way to avoid this pitfall, though. What's the general opinion, should something like the above be added? (I'd be willing to volunteer for the code work.) On a side note, it probably wouldn't be too hard with existing tools to build a "gatekeeper" program to detect obvious kinds of flux in the API when uploading a new package to hackageDB: Check that all old modules are there, export all old functions, and maybe whether all the old functions still have the same type signatures (otherwise warn and ask for confirmation...), etc. Regards, Sven Moritz

5 9