> 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.
Sure, but it'd have to be a different cpp flag because the existing one
is used for a different purpose.
But what purpose does __HADDOCK__ serve if not to inform a file of code that haddock is currently processing it? Perhaps even better would be a __HADDOCK_VERSION__ definition that allows for code to work through changes in the tool. While CPP may not be the most type-safe tool in the world and definitely not ideal for text macro substitution, it does do this simple kind of job very well.
> 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.
Don't you mean the other way around? It's not possible to pass extra
options to these tools via the .cabal file and it's only possible via
configure --$prog-options=
Sorry, when I said configure script, I meant .cabal file.