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.