On Wed, 3 Jan 2001 malcolm-ffi@cs.york.ac.uk wrote:
I am about to add something like {-# CCODE #include <stdio.h> #-} to nhc98 as a stop-gap. Yes, this inevitably differs from whatever mechanism ghc currently uses. So yes, tools like hsc2hs will have to know which compiler they are generating for. Unless anyone wants to have a rethink now? :-)
ghc has -#include <stdio.h> command-line option (if the header name is not in "" or <>, "" are assumed). Any command-line options can be put in the source thus: {-# OPTIONS -#include <stdio.h> #-} (These options currently have to be at the very top of the file and AFAIK recently ghc was changed to accept more than one OPTIONS line.) If nhc adopts that way, it must not generate prototypes itself of course. A signature of a C function derived from Haskell is precise enough to call the function in the right way via a native code generator, but not to generate prototypes with exact constness etc. hsc2hs inserts OPTIONS pragma when generating for ghc. QForeign comes with wrappers for some libraries and a script to output hcflags, ldflags, ldlibs. The script outputs appropriate -#include options for requested libraries. Installation also runs ghc --add-package (on ghc >= 4.09) to specify C includes among other things, and then e.g. -package qforeign-curses option causes inclusion of curses.h, which makes the former script unnecessary. Having correct includes is especially important for ghc, because calls to C functions may be inlined across Haskell modules. A user module doing "import Curses" and being compiled with optiimzation and without appropriate -#include options may cause the C compiler to call function without prototypes, which is not legal in C99 and does not work for argument types like char. -- Marcin 'Qrczak' Kowalczyk