cabal hooks interface

[ross at soi.city.ac.uk]

As an experiment to see what would be useful, I've switched Hugs's
handling of the more peripheral fptools/libraries packages (QuickCheck,
mtl, fgl, HaXml, parsec, HUnit, X11, HGL, OpenGL, GLUT and OpenAL) over
to a variant of Cabal's simple build infrastructure.  The result is in the
CVS repository as hugs98/libraries/tools/HugsSetup.hs.  It's a Cabal setup
script that does configure, build and install, but doesn't yet handle
executables, installed package descriptions or source distributions.
Nor does it handle any version stuff, and it may be a long time before
Hugs can handle that.  Still, it does the basic job, and it works with
all those packages, some of which require system-dependent parameters,
preprocessing, and compilation of FFI stubs.  I hope that some of it
(or equivalent) can be incorporated into Cabal, though I expect you
won't want all of it.

Some extra fields were needed:

	buildPackage    :: Bool,
	ccOptions       :: [String],
	ldOptions       :: [String],
	frameworks      :: [String]

The first one records whether the package configured successfully on
this system, and is therefore buildable.  It was most convenient to add
these as a subrecord of LocalBuildInfo.  With the parsing machinery
in Cabal, it was easy to knock up a parser for a file Setup.buildinfo
containing these fields.  This file can be generated from a template file
Setup.buildinfo.in by ./configure (which might be generated by autoconf
or supplied by the author).

This information would be almost enough to do a similar job for GHC,
including generation of the installed package descriptions, I think.

For Hugs, it is also very convenient (though not absolutely essential)
to have an option --builddir=DIR to setup configure, to specify where
the build output goes.  That goes in LocalBuildInfo too.

Some points I draw from the experiment:

1) The separation between the static Setup.description and the possibly
   generated Setup.buildinfo(.in) makes a clear distinction between the
   invariant interface and system-dependent implementation, except that
   I'd move more fields from the former to the latter.

2) If you decide not to do the interface at the file level, it would
   still make the interface clearer to use two different records for
   the different types of information.

3) Even if you don't do that, it would be helpful for the library to
   take care of the persistence of the extra information returned by
   the configure hook, just as you do now with LocalBuildInfo.