problems with FFI including h files

[Alastair Reid]

> So it looks like you were right.  How can I get ghc to *not* do
> this?  :)

Any time you take two large C programs/libraries and try to merge
them, you're likely to run into preprocessor (or compiler) related
errors like those you describe.  How many libraries provide something
like the following:

  #define TRUE 1
  #define proto(x) x

etc.?


I don't use GHC's ffi often enough to know the exact fix but things to
try are:

1) If using Greencard, use the ffi target instead of the ghc target.
   Both ought to work but the ffi target hopefully doesn't involve
   so much of GHC's header files.

2) Write a thin veneer over the library with its own header file.
   Take care that the header file _does not_ pull in anything other
   than standard header files (i.e., what GHC already pulls in).
   Since you control the header file, you can resolve all conflicts
   yourself.

3) Submit bug reports to ghc team.

   Probably requires you to grok the ghc header files well enough that
   you can submit decent quality reports.  There ought to be a way to
   tell ghc to tell gcc to generate dependency files (as used by many
   Make systems) and/or to keep the preprocessor output (-i on gcc I
   think) - so you could see just where everything comes from.


-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/