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

Claus Reinke claus.reinke at talk21.com
Thu Dec 11 19:19:10 EST 2008

> 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:


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?


More information about the Haskell-Cafe mailing list