- cabal-devel - Haskell.org

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

merge problem
by Ross Paterson 28 Feb '07

28 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 22 Feb '07

22 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 14 Feb '07

14 Feb '07

1 0

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

13 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 06 Feb '07

06 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

Re: Dependencies/backwards compatibility in Hackage
by Björn Bringert 05 Feb '07

05 Feb '07

Sven Moritz Hallberg wrote: > Björn Bringert <bringert(a)cs.chalmers.se>, 2007-02-01 15.36 +0100: >> Ross Paterson wrote: >> I think that the correct solution to this problem would be to make a new >> release of haxr (which used to be XmlRpc) that works with HaXml 1.17. > > But then what is your answer to the problem of things breaking in the > time between the release of HaXml 1.17 and making a new release of haxr? > > -Sven I don't really have one, expect fast development :-). One possibility would be to have a convention about version number changes when libraries make backwards-incompatible API changes. E.g. HaXml should change major version whenever a change would break something that depends on it. Then all libraries which depend on HaXml could specify: Build-depends: HaXml >= 1.13 && < 2 or something like that. The only problem would be that it would be overly restrictive if a HaXml 2.0 comes out that the current version of the depending library actually works with. /Björn

8 13