Cleaning up hooks

[Simon Marlow]

I think the API for hooks is in need of an overhaul.  It has a few problems:

1. it isn't extensible.  When a new command is added, typically
    all the Setup.hs scripts break because they haven't hooked then
    new command.

2. it isn't composable.  It ought to be easy to augment
    PackageDescription in Setup.hs, but it isn't: to do it right,
    you have to modify every hook.

3. It's too complicated.  I'm sure we don't need all those pre- and
    post- hooks.

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.

I can fix 1-3, but 4 is more of a design problem.  I'll outline a possible 
partial solution to 4 later, however.

Anyway, here's the basic idea.  A common thing to want to do in Setup.lhs is to 
modify the PackageDescription, so we provide a way to do that:

modifyPackageDescription
         :: (PackageDescription -> IO PackageDescription)
         -> UserHooks -> UserHooks

modifyPackageDescriptionPostConf
         :: (PackageDescription -> LocalBuildInfo -> IO PackageDescription)
         -> UserHooks -> UserHooks

modifyPackageDescription supplies a function that is run before every command, 
to modify the existing PackageDescription, and it can do IO. 
modifyPackageDescriptionPostConf is similar, except that it does not apply to 
the configure command, and it gets to see the LocalBUildInfo.

These mostly subsume all the preHooks.  For example, 
modifyPackageDescriptionPostConf can be used to read the results of the autoconf 
  script.  (We'll also need to provide a way to merge a new BuildInfo with the 
existing PackageDescription).

The good thing about this is it's extensible and composable.  Adding more 
commands to Cabal won't break Setup.lhs scripts that use these combinators. 
This could also help us solve problem (4) above: Cabal can provide a way to 
output the modified PackageDescription to a file, that can be read in by 
cabal-rpm.  For example, "cabal-setup descr" could output the real 
PackageDescription.

We might still want to hook the real commands, however.  So let's look at 
simplifying the UserHooks type:

  type ConfHook = Args -> ConfigFlags -> PackageDescription -> IO LocalBuildInfo
  type Hook a   = Args -> a -> PackageDescription -> LocalBuildInfo -> IO ()

  data Hooks = Hooks {
   confHook       :: ConfHook,
   postConfHook   :: Hook ConfigFlags
   buildHook      :: Hook BuildFlags,
   makefileHook   :: Hook MakefileFlags,
   cleanHook      :: Hook CleanFlags,
   copyHook       :: Hook CopyFlags,
   installHook    :: Hook InstallFlags,
   sdistHook      :: Hook SDistFlags,
   registerHook   :: Hook RegisterFlags,
   unregisterHook :: Hook UnregisterFlags,
   haddockHook    :: Hook HaddockFlags,
   pfeHook        :: Hook PfeFlags
   }

I've missed out runTests and a few others, but the main idea is that I got rid 
of most the pre- and post-hooks.  The configure command is special, because it 
doesn't see the LocalBuildInfo, so we also need a postConfHook for doing further 
actions after configure (e.g. running the autoconf script).

Suppose we supply thenHook:

  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 }

Alternatively, we could supply addPostBuild, addPreBuild, etc. and hide the 
representation of the Hooks type completely.

Comments?

Cheers,
	Simon