Pragmas for FFI imports

[Duncan Coutts]

On Mon, 2006-02-20 at 19:59 -0800, John Meacham wrote:
> On Fri, Feb 17, 2006 at 01:45:27AM +0200, Einar Karttunen wrote:
> > I would like to propose two pragmas to be included in Haskell'
> > for use with FFI. One for specifying the include file defining
> > the foreign import (INCLUDE in ghc) and an another for defining
> > a library that the foreign import depends on, called FFI_LIB
> > (not implemented at the moment). These changes would not break
> > any existing code.
> 
> Just to expand on this, Einar is working on adding this support to jhc
> right now in his work on the library system in jhc. the semantic we
> decided on was that an
> 
> {-# INCLUDE "foo.h" #-}

I'd just like to note that this shouldn't be the only way to specify
this info. For many real FFI bindings we don't know the right search
paths, defines, libs, lib link-time search paths, lib runtime search
paths etc until we start configuring on the target system. (Though we do
almost always know statically the names of the header files). This
information is often obtained from pkg-config and other similar
foo-config programs.

For example:
$ pkg-config --cflags --libs gtk+-2.0

-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0
-lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0

This information is not universally static. It depends on the machine
were looking at. So it can't be embedded in .hs files. Current practise
is to grok the output of pkg-config and generate the .cabal file at
configure time. Cabal then passes all this info to ghc on the command
line.


So what I'm saying is that it'd be nice to standardise these simple
include pragmas, but I think it'd be more useful to think about
something to help with the bigger cases. Not that I am necessarily
suggesting we standardise the compiler command line syntax but this is
an important (for practical & portability purposes) and yet
under-specified part of the FFI spec.

Perhaps it's not a problem because we can say that Cabal "just knows"
the compiler-specific methods of supplying this information to each
Haskell implementation that Cabal supports. But it's certainly arguable
that this is unsatisfactory.

Duncan