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.