patch applied (cabal): Implement support for hugs and nhc98 package databases

[Duncan Coutts]

On Wed, 2009-12-23 at 16:27 -0800, Duncan Coutts wrote:

> Wed Dec 23 15:35:57 PST 2009  Duncan Coutts <duncan at haskell.org>
>   * Implement support for hugs and nhc98 package databases
>   That is, work out which packages are installed for hugs and nhc98.
>   In both cases there is special support for the core packages.
>   In future both should use the standard method when they supply
>   proper installed package info files for the bundled libraries.

So the goal here is to make Cabal and cabal-install more usable with
hugs and nhc98. In particular we should be able to use cabal-install and
do dependency tracking. There's a couple issues left with inplace
registration.

I've made Cabal read the package information files that come with hugs
2006.9 and nhc98-1.20 despite the fact they're not proper installed
package info files. For future hugs and nhc98 releases we'll be able to
get the full InstalledPackageInfo (rather than just name and version) if
we have the appropriate registration files. These files get installed by
Cabal (at least in the case of hugs, have to check we do the same for
nhc98). We just need these files to be included with the bundled
packages that come with hugs and nhc98. There isn't actually a firmly
established convention on naming for these files. Currently for hugs we
install them as packages/$pkg/package.conf. I'm happy to change that
convention if you prefer.

Whatever we can get hugs and nhc98 to both do should be the defacto
standard for compilers that do not have a hc-pkg. So there will be two
conventions that Cabal groks: hc-pkg and installing a package.conf (the
InstalledPackageInfo) along with the package itself. For new compilers
gaining support for packages (eg EHC) we can present these two supported
options.

> Wed Dec 23 02:39:16 PST 2009  Duncan Coutts <duncan at haskell.org>
>   * Fixes for compiling Cabal with hugs

Note there is no corresponding patch to fix compiling Cabal with nhc98.
I'm not planning on doing this at the moment. While it is possible, it's
really ugly working around the import renaming bugs in nhc98. And it's
not clear that it's worth it since this bug affects most other packages
(based on a quick look).

The main annoyance after the renamer bug is the non-standard exceptions
and lack of some functions in System.IO.Error, in particular the get/set
filename and location. The lack of the unix package will be a problem at
some point.


Duncan