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

[Duncan Coutts]

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