The haddock / clang problem revisited ... root cause found...
tl;dr: - cabal is the culprit - 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. - pre-processing isn't idempotent - when done under clang, it outputs things that ghc. longer: 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): Bugs were filed for both haddock and cabal: https://github.com/haskell/haddock/issues/284 https://github.com/haskell/cabal/issues/1740 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. Full details here: Root cause of haddock / clang failure https://gist.github.com/mzero/d4ba11c567977111749a The correct fix is to change cabal's behavior: Either don't pre-process the fils for Haddock, or don't pass --optghc=-XCPP 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. - Mark
*Re.: Full details here: Root cause of haddock / clang failure https://gist.github.com/mzero/d4ba11c567977111749a* Iain Nicol had submmited a set of commits back in May which addressed the "double pre-process" issue with Haddock. No one had figured out the connection to this set of issues with clang back then. I back-ported them to 1.18 last night https://github.com/haskell/cabal/pull/2010, verfied that these patches do indeed fix the issue, and Johan has committed them to the tree. My plan is to ship haskell platform with Cabal-1.18.1.4 (forthcoming), which is just these patches beyond the Cabal-1.18.1.3 that comes with GHC 7.8.3. This will just be an additional version of the Cabal package, in the package db that ships with the platform. I won't re-build 7.8.3 with a patched Cabal. I don't think there will be any major issues(*) with users getting a package db with two Cabal versions (cabal-install will be built against the later one). - Mark (*) If some proejct depends on package ghc and Cabal, then they will get 1.18.1.3 (as that is what ghc, in 7.8.3 is compiled against in the official bindist). If that project then invokes the haddock operation ... it will double pre-process input if EnableExtension CPP is in allExtensions of the project they are building. I think we're safe...
After discussion on #ghc, my revised plan is that HP 2014.2.0.0 will include just Cabal-1.18.1.3. While the double-pre-processing is "wrong" on all oses, it only systems with clang as the compiler. For the Mac OS X build of HP 2014.2.0.0, I'll be basing it on a "patched" version of GHC 7.8.3 that bumps Cabal to Cabal-1.18.1.4 (and relaxing the hptool build to not balk at this change). I can make that GHC bindist available as well, for those that want GHC w/o HP. - Mark
A patched bindist sounds like a good idea. I've just uploaded Cabal-1.18.1.4 so you should be good to go.
participants (2)
-
Johan Tibell -
Mark Lentczner