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