On Thu, 2008-03-06 at 03:11 -0800, John Meacham wrote:
On Thu, Mar 06, 2008 at 10:43:41AM +0000, Duncan Coutts wrote:
something like this:
foreign import ccall "get_COLOR_PAIRS" colorPairsPtr :: Ptr CInt #def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;}
The problem with that is that it doesn't follow the rules about scope of header files either. Technically the little .h file that hsc2hs generates for you needs to be installed and used by every client package.
no, because your stub functions have a well defined ABI (that was the point of the stub functions after all), so you wouldn't need to keep the header around in general assuming the compiler supported header-less compilation (which ghc doesn't yet AFAIK).
Well ghc does both. If you compile the above -fvia-C then you may well get warnings from gcc about missing prototypes, if you compile -fasm then ghc believes the ABI given by the FFI decl. It also seems I thought the ffi spec said more about headers than it actually does. :-)
I always thought c2hs should actually generate hsc files. That would allow people to compile programs that use c2hs without having to install c2hs on their build machines. hsc2hs is the minimal tool needed to write portable C interfaces so needs to be installed on target systems anyway.
c2hs has to read the header files on your system to be able to check any consistency. I'm not sure why hsc2hs is the minimal tool. It relies on a C compiler where c2hs does not. What happens with Haskell implementations that do not bundle a C compiler (eg ghc in future on win32)? Duncan