On Thu, 2008-12-11 at 16:26 +0100, Sean Leather wrote:
The above is true, but then I ran it with --optghc=-D__HADDOCK__ and that fixed the problem. You see, I didn't know who was actually defining the __HADDOCK__ macro. Now, after looking at code for Haddock and Cabal, I realize it's Cabal.
Does Cabal 1.6.0.1 actually define this macro? I don't see it listed when I run cabal-install with --verbose=3, but I don't know if it's supposed to be printed.
For haddock-0.x, Cabal cpp's all the modules with -D__HADDOCK__ because the old haddock cannot parse all sorts of things. However for haddock-2.x it is important not to use -D__HADDOCK__ because the hacks that people added for haddock-0.x would make haddock-2.x fail. For example they'd simply omit entire declarations. While haddock-0.x didn't really care and parsed and renamed in a sloppy way, haddoxk-2.x is basically ghc and so if the module does not compile then it also cannot be processed via haddock-2.x. The proper solution is to make haddock not fail when it encounters TH code or whatever the original problem was. It can ignore it for now, it just has to not fail. Duncan