"Simon Marlow"
I'm not positive that the simple build infrastructure would be able to take all of the information in the tool-dependendencies into account; for instance, discovering the version of happy and ghc might be a bit tricky and error prone.
We already discover the version of GHC. And it can't be any more tricky than using autoconf :-)
I'm just concerned about parsing version strings from --version; that seems like it may be hard to maintain and very tool-dependent.
I think a small extension to build-depends is warranted - and I think the suggestion I put forward has pretty good bang per buck.
I absolutely agree that this is a good extension to build-depends.
OTOH, maybe Haskell can become the generic packaging language, ... [ daydreaming deleted :-) ]
Oh :(
For Debian packages in most languages, we have a hunk of executable stuff for building and installing, and a relatively small amount of metadata to deal with dependencies and what-have-you. I think we should try to stick to that model wherever possible, of course, improving upon Debian where we can.
That's fine by me, as long as *enough* of the metadata is concrete so that our tools can manipulate it as necessary. There's always going to be a tension here, but I think we can use the dev environment example as a dipstick to tell us whether we've got enough concreteness.
I didn't mean to give you the impression that I don't like your extension (modulo some syntax wibbles) I just want to vote for some care in extending the .cabal file rather than the library or the setup script. peace, isaac