Recent ffi commits

[Alastair Reid]

Here's the current status of the Hugs ffi code:

> - Making sure that the wrapper and dynamic import forms work

Done.

> - Test, test, test

Sigbjorn tested it a bit on Win32.

>   I should try building HGL using --target ffi.

Works.

> - Add something to the test suite.

Testsuite in place.  Could do with testing marshalling/unmarshalling
of each individual type (especially the types subject to promotion in
C).

>   Has to be written so that the tests pass if ffi is disabled or not
> implemented.

Nothing done on that front.  
Static linking should just be a question of dusting off the code in
plugins.c

> - Further contemplation of how to invoke the ffi generation and
> how/whether that should invoke the C compiler

>   The current story is that hugs +G will generate a fresh .c file
> and link it to get a .so file for every .hs file it loads which
> contains ffi code.  This will not look so clever when people install
> their code in read-only directories.

hugs +G only generates code for files mentioned on the command line.
The plan is that libraries supply a Makefile or script which does a
bottom-up traversal of the module graph running hugs +G on each module
containing foreign code.  It would also specify any extra linking
arguments like -lm, -lX11, cbits/Storable.c, -DDEBUG, etc. using the
+L flag

I'm now wondering whether hugs +G should be replaced by a separate
program like runhugs.  

> - Autoconfiscation

>   Code most needing fixed are HsFFI.h and the function
> compileAndLink in ffi.c

Sigbjorn modified ffi.c:compileAndLink to work on Windows with the MS
Visual C compiler.

Autoconfing the code to compile and link the generated code is the
biggest thing on my list at the moment.  I want this question to be
resolved by Hugs because otherwise it has to be tackled by everyone
writing an ffi'd program.

Option1 is to avoid the issue using libtool - but it is GPLd and I had
some bad experiences when I tried to use it many years ago.

Option2 is to key off the compiler and linker type (gcc, msvc, etc)
and the OS type (linux, windows, MacOS X, etc).  Not keen on this
since it tends to create brittle code that needs continual maintenance.

Option 3 (preferred but lots of work) is to do that classic autoconf
thing of trying every option which we've ever heard of until we find
one that works.  That is, I write a small program which tries to do
dynamic loading and I try compiling it with -shared, -bundle, -Z+q and
everything else we can think of until we find a way that loads
correctly.  (While we're at it, we might as well detect whether or not
to add leading underscores to names too - a bit less fragile than the
current test which approaches the problem indirectly.)

>   Mostly porting/stealing code from the GHC autoconf stuff.

I stole the code but haven't yet started using it in HsFFI.h or
configuring the libraries (i.e., CTypes.hs).

> - More libraries (CError, CTypes, ...)

I put in just enough of this to run tests.  I see these as temporary
placeholders until we switch to using the hierarchial modules so I'm
trying to minimise how much work I put into these.

> - Finish the implementation of foreign export.

No progress.

I'm tempted to do the NHC thing and require you to use a monomorphic
type.  People wanting to write portable code can easily do the
translation that Hugs should be doing for you.

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/