> 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. >
That's quite a presumption there. I can certainly write a module that compiles and produces documentation for Haddock but that is different when compiled into binary form. Even without this particular problem, I can see that being potentially useful. 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. > That's certainly the ideal solution; however, it is not there right now. I would be happy to work around it if I could, but I can't. As far as I can tell, I can't pass any flags to Haddock via the Cabal file. I would love to tell Hackage to run Haddock like so, "cabal haddock --haddock-option=--optghc=-D__HADDOCK__", but I don't know how. This adventure has exposed a major problem with Cabal that I have run into several times. It supports a limited set of external tools (e.g. Haddock, Alex, Happy, etc.), but it supports them in a limited way. Primarily, it is not possible to pass options to these tools (at least) through the configure script. Also, regarding transparency with Hackage: is it possible to determine exactly which tools (e.g. Haddock version) are being used on the server? I would like to see a list on the website of the exact operations that will be applied to my package once uploaded. Regards, Sean
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
