Compiler modes / FFI / forcing CPP

[Simon Marlow]

On 29/04/2009 23:48, Philip Hölzenspies wrote:
> Dear GHC-ers,
>
>  From earlier questions, it seems no one wants to get down and dirty
> with linker tricks in ghc. I'm now looking over an alternative solution.
>
> I'm currently trying to use SDL. There's a wrapper on hackage, which
> works fine under Linux, but it takes some tinkering under Mac OS X,
> because OS X needs instantiated Cocoa stuff for the SDL entry point.
> Long story short, to use SDL with ghc on the OS X, a little wrapper
> c-file needs to be written, because the linker will find a 'main'
> function in libSDLmain.a which expects a function 'SDL_main' as an entry
> point into the user code.
>
> I have written a small c file that can be used to wrap around any
> haskell module (see below), based on the macro (cpp) definition of
> MODNAME. I can compile this c file with gcc, for, let's say a module Foo
> with entry point Foo.bar (so, if we could still have ghc make the entry
> point, we would say ghc -main-is Foo.bar):
>
> gcc -c -DMODNAME=Foo -D"ENTRYPOINT=bar();" -o Foo_entry.o entry.c
>
> However, this only works after I explicitly add ghc's "include" dir to
> my search path so that HsFFI.h can be found. Before I had this
> pre-processor trick, I could simply feed the c file to ghc, together
> with all my haskell files. Ghc then simply adds the correct includes and
> feeds the c file to the c compiler. Unfortunately, giving ghc the above
> -D options doesn't do much good.
>
> The problem seems to lie with the suffix recognition ghc does. I took
> this from [1]. With the -cpp switch, the c pre-processor is used, but
> only when the file has a .hs suffix. The c compiler is only run when the
> file has a .c suffix. Using -x .hs puts the file correctly through the c
> pre-processor, but then fails to compile it, because it's not haskell
> code. Using -x .c doesn't do pre-processing (even with -cpp). I tried to
> compile this wrapper using this command (assume now that we have
> Foo.hsMain as an entry point):
>
> ghc -cpp -pgmP cc -optP-E -DMODNAME=Foo -o Foo_entry.o entry.c
>
> (Notice that you can't just use cpp, because on OS X that's a shell
> script that doesn't provide CPPs full strength, so you want "cc -E".)
> This doesn't work:
>
> entry.c:27:2: error: #error MODNAME undefined!
>
> Trying to be more explicit as to where the -D should go:
>
> ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o entry.c
>
> does exactly the same. Now faking .hs:
>
> ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o -x hs entry.c
>
> which produces the error (coming from stdio.h inclusion):
>
> /usr/include/i386/_types.h:37:28: parse error on input `;'
>
> So, I guess my question is: Is it possible to let a c input file of ghc
> pass through *both* the c pre-processor *and* the c compiler?

Maybe I'm missing something, but what's wrong with

   ghc -c -optc-DMODNAME=Foo -o Foo_entry.o entry.c

Cheers,
	Simon