Cleaning up hooks
Simon Marlow
simonmarhaskell at gmail.com
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?
Cheers,
Simon
More information about the cabal-devel
mailing list