ffihugs, Storable.so

[Alastair Reid]

> 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