Cleaning up hooks

Simon Marlow simonmarhaskell at
Thu May 3 03:47:08 EDT 2007

Ian Lynagh wrote:
> On Tue, Apr 24, 2007 at 09:45:54AM +0100, Simon Marlow wrote:
>> I think the API for hooks is in need of an overhaul.
> I agree.
>> 4. tools that build on Cabal (e.g. cabal-rpm) don't work with hooks.
>>    If your Setup.hs uses hooks to modify the PackageDescrption, then
>>    cabal-rpm won't see the modifications.
> That's something I think you just shouldn't be doing, and hopefully we
> won't need to after this summer.

Yes, I quite agree.  I saw the code in e.g. base/Setup.hs, and noticed how it 
broke with 'setup makefile', and decided there must be a better way.  Certainly 
configurations are an even better way.

>>  thenHook :: Hook a -> Hook a -> Hook a
>>  thenHook hook1 hook2 args flags pd lbi = do
>>    hook1 args flags pd lbi
>>    hook2 args flags pd lbi
>> Then to add a post-hook to the build command you could do this:
>>  addPostBuild :: Hook BuildFlags -> Hooks -> Hooks
>>  addPostBuild hook hooks
>>    = hooks { buildHook = buildHook hooks `thenHook` hook }
> I think most of the time we would want `thenHooks` (defined in terms of
> thenHook), e.g. (with the current names) we'd have something like:
>     defaultBuildHooks = simpleBuildHooks `thenHooks` configureBuildBooks
> where configureBuildBooks might define a confHook (to run ./configure)
> and a cleanHook (to remove config.log etc).

Right, I can imagine that might be more convenient.

So we agree in principle that removing all the pre/post hooks from UserHooks and 
providing thenHook/thenHooks would be an improvement?  It's a bit of a 
no-brainer refactoring, I might do it when I'm feeling bored sometime.  Or maybe 
Thomas could do it as part of the SOC project?


More information about the cabal-devel mailing list