[fetter-devel] gccxml-config and virtual-funcall on the mac

[Eric Bergstrome]

Hi,
I've been experimenting a little with verrazano this weekend to see if I can
use it to inject more lisp into my work-day.

My current environment is SBCL, OS X, x86, gcc; with gccxml 0.7.0, cffi
0.9.2, and the darcs head revision of verrazano as of a couple of days ago.

So far I've been able to load in a trivial c++ dylib I made from xcode
specifically for verrazano testing and use the generated bindings to call
functions and methods.

Here are a few adjustments that were needed:

1. I had to use the --gccxml-config option of gccxml to work around a
problem where the automatic configuration was malformed.  I got error
messages saying something like "too many filenames".  I used --debug to see
the configuration options it was using and removed the malformed options.
 Put the touched up config in a file and used --gccxml-config as described
in the gccxml --help output.  The malformed options were mostly related to
frameworks, so I may have to come back to this if I need access to functions
defined in a framework.

2. The next thing I noticed was that my test bindings would not load without
errors.  The problem was in the use of VIRTUAL-FUNCALL.  It seems that CFFI
has changed FOREIGN-FUNCALL and added FOREIGN-FUNCALL-POINTER.  After a
little reading of the CFFI source, I came up with the following -- which
seems to work but is by no means well-tested or well-understood:

(defmacro virtual-funcall (pobj indx coff &body body)
  `(foreign-funcall-pointer (vtable-lookup ,pobj ,indx ,coff) nil , at body))

In particular, I don't understand the purpose of the options-argument of
FOREIGN-FUNCALL-POINTER so I just pass nil.  FOREIGN-FUNCALL effectively
does the same when you only pass a function name rather than (name .
options).

With some more luck, I'll be building on hundreds of thousands of lines of
c++ code, from the REPL, at work, during the day.  Awesome!  At a minimum,
there's still name conversion, lisp wrappers, templates, and finalization to
figure out.  So I'll post more as I go.

By the way, I don't see myself checking in lisp code at work any time soon.
 I'll be using it for prototyping, debugging, and various other odd jobs.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/fetter-devel/attachments/20071029/3c68d749/attachment.html>