Redundancy in the build system for packages

[Simon Marlow]

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 
> outcome.
> 
> 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.

Cheers,
	Simon