Yes.
I'm in the process of changing FSBV (and GSLL, and to some extent GSD) with two intertwined goals. One goal is to have all foreign struct interface handled in one place, so that e.g. complex-double-c (in GSD) and sf-result (in GSLL) are handled the same way. Since this is (for now) being done in FSBV, it has the effect of splitting FSBV into two parts, say "FS" (foreign structures) and "FSBV" (foreign structures by value). The first part will handle conversions between foreign and CL objects, as with #'object and #'(setf object). It happens that GSD defines complex foreign types but call functions with those arguments by value; GSLL optionally uses them by value.
The second goal is a long-term one of integrating FSBV into CFFI. When I do that, the part that just addresses foreign structures (not by-value calls) will (I'm hoping) be loaded automatically. Then, foreign-array will only require CFFI (which it already does). The "by value" part will be an optional system for CFFI users, because it requires libffi.
I hope the explanation is clear. To answer your specific question: I've pushed a new version of FSBV; in that version, you only have to load pkgdcl.lisp and convert.lisp, and you won't need libffi. Sorry for the awkward state; for the time being FSBV is mandatory, but I'm hoping that goes away in the not-too-distant future. I didn't make a separate branch because it does work as-is, and I figured most people were getting these systems via quicklisp, which already installs the entire FSBV.
Liam
On Tue, Nov 30, 2010 at 11:58 AM, Sumant Oemrawsingh soemraws@xs4all.nl wrote:
Hi Liam,
Recently, I tried getting foreign-array working on windows (with sbcl). I noticed that foreign-array uses fsbv (apparently) and fsbv uses libffi. I haven't dug around in the code yet, but I was wondering if you have a quick explanation why libffi is used, and why cffi is not sufficient. The reason I ask is because I'm wondering if it would be possible to hack it under windows so it doesn't need libffi (which apparently is quite difficult to get working there).
Thanks, Sumant
GSLL-devel mailing list GSLL-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel