- cabal-devel - Haskell.org

patch applied (cabal): Compile a .c rather than a .hs file to make a .o file in ld -x configure test
by Duncan Coutts 24 Oct '07

24 Oct '07

Wed Oct 24 08:05:05 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Compile a .c rather than a .hs file to make a .o file in ld -x configure test Since when bootstrapping ghc we're not in any position to compile .hs files that easily. M ./Distribution/Simple/GHC.hs -4 +4

1 0

patch applied (cabal): Create the dist/ dir early in the configuration process
by Duncan Coutts 24 Oct '07

24 Oct '07

Wed Oct 24 06:35:54 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Create the dist/ dir early in the configuration process M ./Distribution/Simple/Configure.hs -1 +3

1 0

patch applied (cabal): Create temp files in dist, since it is now guaranteed to exist
by Duncan Coutts 24 Oct '07

24 Oct '07

Wed Oct 24 03:28:50 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Create temp files in dist, since it is now guaranteed to exist M ./Distribution/Simple/Program.hs -1 +1

1 0

Re: Packages within a package
by Duncan Coutts 24 Oct '07

24 Oct '07

On Wed, 2007-10-24 at 13:08 -0400, John D. Ramsdell wrote: > Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> writes: > > > I think I'm claiming that developers want support for developing > > systems as a unit but distribution can be as a collection of > > components rather than as a unit. > > Do you believe it is a bad idea to expect that Cabal be the > appropriate tool for developing systems as a unit? No. > Maybe Cabal should do just one thing, and one thing well, package > components of systems into the smallest units available for > distribution. > > I had been thinking of Cabal as a development tool as well as a > packaging tool, similar to autoconf/automake, but perhaps Cabal is > really meant to be similar to rpmbuild and dpkg-buildpackage. Maybe > thinking of it as a development tool was an error on my part. Currently it only helps with a single package at a time, so dealing with multi-package systems is cumbersome. The intention is to extend it to help developers working with multi-package systems. My claim is that all that requires is improvements in the tools, not a change in the notion of a package as the unit of distribution and dependency. > For my application, I suppose I could use autoconf/automake to develop > the software, install the executables, build a Cabal package > description, and then use it with Cabal to make the library available > as a package. Is this usage more inline with your intentions? We'd like to kill off autoconf as much as possible. :-) So we hope that developers will work directly with Cabal rather than generating Cabal packages from other systems. As I said before, my personal example is Gtk2Hs which is a relatively complex multi-package system. Currently it is impossible to package it with Cabal but we're getting closer. Gtk2Hs currently uses autoconf/automake and I can build everything with: ./configure make and I can rebuild everything with just make. And if there's nothing to do it takes a fraction of a second to work this out. I'd like to get to that stage with cabal. I'd like to say: cabal configure cabal build Or maybe just cabal build to get default configure parameters. And if I run cabal sdist I'd expect it to generate twelve .tar.gz packages that I can upload to hackage. With that kind of infrastructure there's lots of fun stuff we could do, like continuous build and test: cabal build --continuous & To get there of course we'll need lots of help from lots of people. I'd like to encourage people to get involved. Duncan

2 1

Patch for unlit code
by David Waern 24 Oct '07

24 Oct '07

Here's a patch that fixes a bug in the Unlit pre-processor.

1 0

patch applied (cabal-branches/cabal-1.2): Adjust verbosity of a step in configure
by Duncan Coutts 24 Oct '07

24 Oct '07

Wed Oct 24 09:07:58 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Adjust verbosity of a step in configure M ./Distribution/Simple/Configure.hs -1 +1

1 0

patch applied (cabal-branches/cabal-1.2): Compile a .c rather than a .hs file to make a .o file in ld -x configure test
by Duncan Coutts 24 Oct '07

24 Oct '07

Wed Oct 24 08:05:05 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Compile a .c rather than a .hs file to make a .o file in ld -x configure test Since when bootstrapping ghc we're not in any position to compile .hs files that easily. M ./Distribution/Simple/GHC.hs -4 +4

1 0

patch applied (cabal-branches/cabal-1.2): Create the dist/ dir early in the configuration process
by Duncan Coutts 24 Oct '07

24 Oct '07

Wed Oct 24 06:35:54 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Create the dist/ dir early in the configuration process M ./Distribution/Simple/Configure.hs -1 +3

1 0

patch applied (cabal-branches/cabal-1.2): Create temp files in dist, since it is now guaranteed to exist
by Duncan Coutts 24 Oct '07

24 Oct '07

Wed Oct 24 03:28:50 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Create temp files in dist, since it is now guaranteed to exist M ./Distribution/Simple/Program.hs -1 +1

1 0

patch applied (cabal-branches/cabal-1.2): pass cpp-options to cpphs
by Duncan Coutts 24 Oct '07

24 Oct '07

Tue Oct 23 11:42:10 PDT 2007 Ross Paterson <ross(a)soi.city.ac.uk> * pass cpp-options to cpphs M ./Distribution/Simple/PreProcess.hs -1 +1

1 0