I've changed configure in CVS so that the FFI is enabled by default if one of the header files for dynamic loading is found (the same test you use in machdep.c for defining getDLL() and friends). I'm assuming that that means static imports should be available, though dynamic ones may not be. Is that right?
Sounds great. Yes, static export and dynamic import should be fine. Static import doesn't work on any platform and dynamic export (ummmm, I think that's called 'foreign import wrapper') requires porting. [Incidentally, it'd be nice if the test suite could react to configure-time options and discoveries so that if you didn't enable something, it prints a short notice that it isn't checking instead of checking and failing (or it runs a different check to make sure error messages are cool).]
Levent (and Oliver Braun) asked why ffi-using modules are compiled in the install directories (rather than in the build tree and merely copied on install, like everything else). Is that because the alternative doesn't work if your build tree is full of symbolic links, due to path canonicalization?
I think it is currently necessary to install HsFFI.h for ffihugs to work because it expects it to be in {Hugs}/include. Specifying something like +L'-I$build_dir/includes' when invoking ffihugs might be enough to fix it. If you wanted to try to overcome this in the C code instead of the makefile, the code is: /* the path to HsFFI.h */ insert(" \"-I"); insert(hugsdir()); insertChar(SLASH); insert("include\""); in machdep.c::compileAndLink (line 2192). As far as I know, symbolic links are not an issue (though I guess it's possible). -- Alastair