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

Wed Dec 23 15:35:57 PST 2009 Duncan Coutts * 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 * 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