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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
