<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>> That's quite a presumption there. I can certainly write a module that<br>
> compiles and produces documentation for Haddock but that is different<br>
> when compiled into binary form. Even without this particular problem,<br>
> I can see that being potentially useful.<br>
<br>
</div>Sure, but it'd have to be a different cpp flag because the existing one<br>
is used for a different purpose.<br>
<div></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>> This adventure has exposed a major problem with Cabal that I have run<br>
> into several times. It supports a limited set of external tools (e.g.<br>
> Haddock, Alex, Happy, etc.), but it supports them in a limited way.<br>
> Primarily, it is not possible to pass options to these tools (at<br>
> least) through the configure script.<br>
<br>
</div>Don't you mean the other way around? It's not possible to pass extra<br>
options to these tools via the .cabal file and it's only possible via<br>
configure --$prog-options=<br>
<div></div></blockquote><div><br>Sorry, when I said configure script, I meant .cabal file.<br><br></div></div>Regards,<br>Sean<br>