cabal hooks interface

[ross at soi.city.ac.uk]

On Fri, Dec 10, 2004 at 08:40:35AM -0800, Isaac Jones wrote:
> The commands need a way to pass information between one-another.  If
> we use 'system' to run external commands, then the only way to do that
> is to dump a file that cabal itself knows how to read back in, and
> cabal has to know where it is.  If we rather use the preHooks, Angela
> can do whatever she wants to get the information between phases, so
> long as she returns a PackageDescription.
> 
> If we use 'system' calls, then Cabal must specify the names of the
> scripts and the format and location of the files they output (or
> preHooks with an interface similar to mine to read them back in).  If
> Cabal use the preHooks, then all we need to specify is the type of the
> functions.
> 
> The preHooks let the user do the obvious thing, which is to read and
> write to a separate description file of their choosing, or to do
> something as strange as they like to get the package description.
> 
> In any case, you can just say defaultUserFunctions{postInst=system
> "./postinst.hs">> readPackageDescription "thePlaceIKnowItWillEndUp"}.

Ah, that's why I was confused: I had thought that at least Cabal would
manage the persistence for them so the hooks would be independent.

I think this is where I'm supposed to mutter "sometimes it takes a tough
man to make a tender chicken".

You're very concerned about keeping the interface as simple as possible,
and providing maximum flexibility to the library author.  The flipside
of this is that each author of a library whose build is system-dependent
must face the complexity you've excluded.  They will end up redoing
much the same thing as the previous person only slightly differently,
inventing their own file format, writing their own printer and parser.
If they write a preConfig hook, they'll need all the others too.
Adding utilities for this to the library will help, but that will
complicate the interface too, and they still have to do the rest.
Maintaining that will be painful.

If Cabal were to specify just a little more, the overwhelming majority
of library authors would need to write no more than System.description
and a preConfig hook to get system-dependent build information.  The few
who need more flexibility can write it themselves, but most people won't
want to do that, and are likely to do a poorer job of it than a general
tool would.