<div dir="ltr"><div>tl;dr:</div><div><ul><li>cabal is the culprit</li><li>If you have the `Extensions: CPP` directive in your .cabal file, then when invoking haddock, cabal causes every file to be pre-processed twice in sequence.</li>

<li>pre-processing isn't idempotent</li><li>when done under clang, it outputs things that ghc.<br></li></ul></div><div><br></div><div>longer:</div><div><br></div>Regarding the ellusive problem whereby haddock for some packages fails on ghc-7.8.3 / haddock-2.14.2 systems with clang (as in OS X 10.9):<div>

<br></div><div>Bugs were filed for both haddock and cabal:</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><a href="https://github.com/haskell/haddock/issues/284" target="_blank">https://github.com/haskell/haddock/issues/284</a></div><div><a href="https://github.com/haskell/cabal/issues/1740" target="_blank">https://github.com/haskell/cabal/issues/1740</a></div>


<div><br></div></blockquote>I've been trying to find a work-around before releasing the platform for OS X. In sleuthing this I found the root cause: cabal.<div><br></div><div>Full details here: <a href="https://gist.github.com/mzero/d4ba11c567977111749a">Root cause of haddock / clang failure</a><br>

<div><br></div></div><div>The correct fix is to change cabal's behavior: Either don't pre-process the fils for Haddock, or don't pass --optghc=-XCPP</div><div><br></div><div>There is no good work around: We could add -optP-P to all compilations, but that breaks line numbers for everything. We could wrap haddock to remove the --optghc=-XCPP, but that will break hand invocations of haddock.</div>

<div><br></div><div>- Mark</div><div><br></div></div>