scope of header files

[Duncan Coutts]

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