ross@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