[Haskell-cafe] Problem with haddock 2.3.0 (again)

[Claus Reinke]

> 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