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? Then again, haddock depends on ghc and specific versions of other packages, so you might not want to depend on haddock.. 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 - cabal supports package version macros, but they aren't available everywhere, due to the way they are implemented - tools like haddock aren't tracked by cabal - it would be nice if every tool executable also installed a tool package with version/ path information (similar to ghc-paths for ghc), as that would be tracked by cabal - 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? Claus