cabal hooks interface

[Isaac Jones]

ross at soi.city.ac.uk writes:

(snip)
> 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.  

I think that resisting feature-creep is a good policy with the threat
of "reinventing make" looming.  I want cabal to be maintainable in the
long-run, for one thing.

> 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.

I am trying to be accommodating, actually.

I prefer the function-hooks because I think they're more flexible and
build on Haskell's strengths.  I certainly want runhaskell to appear
and be reliable, but so far, cabal does not depend on it, and I'd
prefer to keep it that way.  runhaskell is a pretty simple thing, but
there are a number of issues that need to be addressed, and it has
several moving parts (compiler registration and un-registration,
default compiler, distribution, etc.).  I don't think cabal should
fall down if one of those parts breaks.

> 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.

We could provide default hooks that read and write to a pre-determined
file (except for preConf, which the user will want to provide).

The information that the later commands need is exactly what's in
PackageDescription, which is why that's what we're returning in the
hooks.  I'm not sure I see an advantage in adding another file and
another parser for the build information.  If you want to generate a
file during configure, you can generate a Setup.description-formated
file.  

You'd have:

-- |all return nothing, provided for convenience
emptyUserFunctions  :: UserFunctions
...
-- |the default name for generated description file
generatedDescriptionFile = "Setup.description.generated"

 -- |read and write to Setup.description.generated or something
defaultUserFunctions :: UserFunctions
defaultUserFunctions
    = UserFunctions
       {preConf = return Nothing, -- override by making generatedDescriptionFile
        preBuild = do exists <- doesFileExist generatedDescriptionFile
                      when exists (readPackageDescription generatedDescriptionFile)
                      ...
        etc.
       }

We have a new data structure which is very simple, if repetitive, a
few new variables, and a new defaultMain function.  There will be some
repetition between the required fields of Setup.description and
generatedDescriptionFile, and I don't like that, but I sorta like the
idea of having a new parser and datafile format (for build info) even
less.

------------------------------------------------------------

Now Angela just says something like
main
   = defaultMainWithHooks defaultUserFunctions{preConf=angelasPreConf}

I think this gives you everything you want.  

peace,

  isaac