FFI Definition

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Tue May 29 03:34:11 EDT 2001


[Sorry for being absent from this discussion for a while.
Teaching took its share...]

Sven Panne <Sven_Panne at BetaResearch.de> wrote,

> Simon Marlow wrote:
> 
> > The reason for not putting them in the source is because the names of
> > libraries change from system to system but their APIs don't.  It's
> > possible to write a portable binding to an API if you don't have to
> > include the libraries,  but including the library names requires
> > information from the system, which is normally picked up by a configure
> > script. [...]
> 
> I'd go even one step further: Often even the names of #include files
> differ for the same API, or you have to #include some other headers
> first, etc., just take a look into GHC's RTS for example. If we specify
> #includes in the FFI, we effectively resort to autoconf or something
> like that in our hand-made #include files most of the time, I fear.
> (or clutter up the Haskell sources with #if #endif :-P ) But most
> people on this list think different and you don't have to use this
> feature, so I can live with that.

For .h files, you can always define your own .h file, which
includes everything in a system-dependent manner.  For
libraries that have to be linked in, a similar mechanism is
not feasible.  Therefore, it is reasonable to handle `.h's
and libs differently.

Cheers,
Manuel




More information about the FFI mailing list