Hello 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. - Einar Karttunen
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" #-} in any module will have the equivalent effect of adding an include to each foreign ccall in the current module like so: foreign import ccall "foo.h foo" foo :: Int -> Int I say equivalent effect because I know ghc treats includes somewhat differently depending on where they are specified but the eventual user visible effect is the same (I think, if I understand things) the same will be true of the FFI_LIB flag, {-# FFI_LIB libm #-} foreign import ccall "-lm foo.h foo" foo :: Int -> Int (note: jhc non-standard syntax extension here) John -- John Meacham - ⑆repetae.net⑆john⑈
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 note that nhc98 has had the pragma FFI_LIB for a long time (under the name OPTIONS_LINK). Regards, Malcolm
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
On 21.02 11:50, Duncan Coutts wrote:
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.
Yes, both -I and -L options can vary across machines and they can be supported by Cabal. The name of the library is static for most the simple cases and for the rest one usually ends up using autoconf etc. Of course with CPP there is a way to generate the pragmas dynamically, but this is not something I would advertise.
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.
But it is not possible to have e.g. Foo.Bar.MySQL (depends on -lmysql) Foo.Bar.PgSQL (depends on -lpq) and with suitable optional compiler support create an executable that depends only on those libraries that it actually uses. This is not possible if library dependencies are per-package. Of course compilers can still default to actually handling dependencies on a per package level if they want without breaking anything. - Einar Karttunen
participants (4)
-
Duncan Coutts -
Einar Karttunen -
John Meacham -
Malcolm Wallace