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/