Redundancy in the build system for packages
simonmarhaskell at gmail.com
Thu Jan 4 05:11:51 EST 2007
Sven Panne wrote:
> Looking at our current technology for building packages below ghc/libraries, I
> think that for each package there are 2 redundant files: package.conf.in and
> prologue.txt. If I see things correctly, almost all information is already in
> the foo.cabal files, so the question is: What are the plans for removing this
> redundancy? I think this has been discussed before, but I can't remember the
> The background behind this: When adding or removing Cabal packages via RPM,
> one has to regenerate the Haddock "Contents" page and the "Index" pages to
> match the set of currently installed Cabal packages. This is similar to what
> has to be done for info pages via install-info. To do this, one needs the
> package descriptions, which should be taken from the "description" fields of
> the installed Cabal packages (note that these should contain Haddock markup
> then). But currently foo.cabal and package.conf.in are very out-of-sync for
> most packages (empty/different descriptions, even differing package versions
> (fgl!), bug reports due to inconsistent list of modules, etc.).
Ian is working on using Cabal to build the packages. This is definitely the
direction we want to go.
There are some problems, though. These are the ones that spring to mind, I'm
sure there are others:
- bootstrapping from HC files. Cabal doesn't know how to do this, and
the fact that Cabal is a Haskell library itself presents some
bootstrapping "issues" :-)
- parallel make: currently we can take advantage of 'make -j' when
building libraries, Cabal can't do this (yet).
- The GHC package: due to a long-standing hard-to-fix bug in GHC, it can't
build itself with optimisation and --make, which means that Cabal can't be
used to build the GHC package, so we'd need to retain the old build
system infrastructure in order to build the GHC package, for now anyway.
- we need some extensions to Cabal in order to support conditionals in
the .cabal file. I think this is the most urgent sticking point, in fact.
The design is more or less complete (see recent discussion on
cabal-devel at haskell.org) but no implementation as yet.
More information about the Cvs-ghc