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