On Fri, 2008-12-12 at 00:19 +0000, Claus Reinke wrote:
Still, you might find something useful in the discussion for this ticket:
Cabal should support Cabal-version-dependent Setup.hs http://hackage.haskell.org/trac/hackage/ticket/326
or, more directly:
http://www.haskell.org/pipermail/cabal-devel/2008-August/003576.html
so, if you add the haddock package to your build-depends, that might give you a MIN_VERSION_haddock(_,_,_) already, without setup fiddling - Duncan?
Right, but it's not a good idea.
Then again, haddock depends on ghc and specific versions of other packages, so you might not want to depend on haddock..
A reason amongst several.
Looks like one of those frustrating corners of packaging
- haddock wants to be up to date wrt ghc, so claims not to need a macro; but it isn't complete, ghc keeps developing, so the macro that shouldn't be needed in theory would be useful in practice
It seems to me this is not insolvable. Haddock does get updated just to be able to build with ghc at all. All it needs is to be able to ignore bits of the ghc AST that it does not understand. I expect in practise it's a bit more subtle than that, but I'd like to hope that it isn't.
- cabal supports package version macros, but they aren't available everywhere, due to the way they are implemented
That's kind of by design. A package should not know the versions of packages it does not depend on.
- package version dependent settings in .cabal/Setup.hs would be useful; apart from the special case of cabal-version-dependent code in Setup.hs, perhaps something like this, to set options depending on package availability
if flag(haddock2) build-depends: haddock > 2 haddock-options: -D__HADDOCK2__
only that options fields are limited to a predefined set, not including haddock? Shouldn't options fields be available for every use of .cabal, like haddocking?
The conflict here is between a notion of packages as descriptions and as active agents. In the model where packages simply describe what they are there is no need for the package itself to say what options you should use for random external tools, after all how should the package know how the user or package manager is using that tool and thus what options are appropriate in what circumstances. The active agent view says that packages get to dictate exactly what happens, to the extent of providing opaque scripts to perform those actions. We've kind of got a balance of the two. Package authors say what language features or compiler options are essential to build their code, while the user/package manager gets to decide all the configuration options and do things like pass special flags to special tools (since they're the ones invoking them and they know about the context and environment). If at all possible I would like to avoid adding arbitrary prog-options: fields into the .cabal file. I don't think it's the right balance between the package author and package builder. There is also a danger in adding lots of per-package hacks when there is a neat global solution, especially because when that global solution is implemented the per-package hacks will probably break. Duncan