Cabal hooks

[Ross Paterson]

To recap, the current setup in Distribution.Simple with the default
hooks goes like this:
- the package description file (formerly Setup.description,
  now <package>.cabal) can contain values for all the fields in
  PackageDescription, but it should be system-independent, and not
  modified by the Cabal script.
- system-dependent information to override some of these fields can be put
  in a second file (Setup.buildinfo) that can be created by the preConf
  step (e.g. by running ./configure).  However this shouldn't override
  certain static fields, including name and version.  Prehooks read this
  second file and merge it with the package description for use by the
  various actions.

On Tue, Jan 11, 2005 at 02:33:52PM +0200, Krasimir Angelov wrote:
> I am trying to cabalize HSQL. There is a simple ./configure script
> which performs some simple checks. Now I would like to perform these
> checks from Setup.lhs using Cabal hooks. The hooks API looks a little
> bit strange for me. The preConf hooks returns (Maybe
> PackageDescription) which after that is merged with the basic
> description. The Setup.buildinfo file contains only the hooked
> description instead of merged one. The parser requires to have package
> name and version, in order to properly parse the description. I need
> to return the right name and version from preConf hook to satisfy this
> restriction. I can't do this without re-reading the original
> description from Setup.description.

Krasimir's initial request (getting values from ./configure used via
Setup.buildinfo) can be handled by defaultUserHooks, but in off-line
discussions Krasimir has said that he also wants to be able to put values
supplied on the command line into Setup.buildinfo.  That doesn't work
at present, because the only way to create Setup.buildinfo from inside
the Cabal script is to use writePackageDescription, and that needs a
package name and version to produce something that readPackageDescription
can read, and moreover unionPackageDescription wants them to be the same
as the original ones.

> Isn't it simpler to change the hooks type to something like:
> 
> PackageDescription -> IO PackageDescription
> 
> where the argument is the original description and the result is the
> possible updated one? This avoids the need of merging and simplifies
> the library code.

It replaces the need for merging with the need to check that they haven't
changed the fields they weren't supposed to.

Other alternatives:
- have the prehooks return a type other than PackageDescription,
  containing only the fields they're allowed to override.  That means
  a different parser for buildinfo files.
- introduce a variant of writePackageDescription that only writes the
  fields they're allowed to override (or only writes non-empty fields).