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@haskell.org) but no implementation as yet.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
