I'm calling haddock myself. Cabal might have some special magic for CPP, when I searched for "haddock CPP" I got some old bugs about adding cabal support. So presumably it's possible. On Jul 12, 2013 1:15 PM, "Felipe Almeida Lessa" wrote:

Are you using `cabal haddock` or calling haddock manually?

Cheers,

On Fri, Jul 12, 2013 at 3:25 PM, Evan Laforge wrote:

...

So haddock ignores {-# LANGUAGE CPP #-}, which makes it crash on any file that uses it. But if you pass --optghc=-cpp, it runs CPP on everything, which makes it crash on any file that uses string gaps, or happens to contain a /*. /* is rare and easily fixed, but not string gaps.

It looks like a workaround would be to manually inspect the files for LANGUAGE CPP and run two haddock passes, but then I would have to get the two passes to cooperate creating a single TOC and index.

Isn't there some way to run haddock on files that use CPP?

In the broader scheme, it seems perverse to be using CPP in the first place. I use it to configure imports and exports, e.g. to swap out a driver backend on different OSes, and to export more symbols when testing. Would it make sense to have a haskell version of CPP that provides only these features (e.g. just #ifdef, #else, #endif, and #define) and leaves out the problematic C comments and backslash expectations?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Felipe.

This is not true either. Cabal preprocesses files that explicitly indicate (via an extension) that they need to be preprocessed. For example, a .cpphs file will be preprocessed to yield an .hs file. .hs files are never preprocessed by Cabal, as far as I can tell. If you have an .hs file with {-# LANGUAGE CPP #-}, it is a compiler's job to detect it and run the preprocessor. But haddock uses the GHC API (which knows how to do the above), so there shouldn't be issues with that. Roman * Felipe Almeida Lessa [2013-07-12 18:34:32-0300]

I guess that cabal preprocesses the files before calling Haddock then. Perhaps that's why it asks me to `cabal configure` before `cabal haddock`ing =). If you're able to switch over to cabal, that may be the easiest solution.

Cheers,

On Fri, Jul 12, 2013 at 6:31 PM, Evan Laforge wrote:

...

I'm calling haddock myself. Cabal might have some special magic for CPP, when I searched for "haddock CPP" I got some old bugs about adding cabal support. So presumably it's possible.

On Jul 12, 2013 1:15 PM, "Felipe Almeida Lessa" wrote:

...

Are you using `cabal haddock` or calling haddock manually?

Cheers,

On Fri, Jul 12, 2013 at 3:25 PM, Evan Laforge wrote:

...

So haddock ignores {-# LANGUAGE CPP #-}, which makes it crash on any file that uses it. But if you pass --optghc=-cpp, it runs CPP on everything, which makes it crash on any file that uses string gaps, or happens to contain a /*. /* is rare and easily fixed, but not string gaps.

It looks like a workaround would be to manually inspect the files for LANGUAGE CPP and run two haddock passes, but then I would have to get the two passes to cooperate creating a single TOC and index.

Isn't there some way to run haddock on files that use CPP?

In the broader scheme, it seems perverse to be using CPP in the first place. I use it to configure imports and exports, e.g. to swap out a driver backend on different OSes, and to export more symbols when testing. Would it make sense to have a haskell version of CPP that provides only these features (e.g. just #ifdef, #else, #endif, and #define) and leaves out the problematic C comments and backslash expectations?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Felipe.

-- Felipe.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe