On 10/5/13 9:11 AM, Stefan Monnier wrote:
> As you may remember, I'd really like for Emacs to grow some kind of FFI.
> Last time we discussed it, I mostly remember the following points being made:
> - An FFI can be a lot of work, and the benefit is not as obvious as it seems.
> - Emacs-Guile would give us an FFI for free.
> - The xwidget branch indirectly gives us some limited FFI.
> 
> The Emacs-Guile route seems promising, but I'm not sure I want to depend
> on its schedule.  The xwidget one seems a bit too limited for my taste.
> And I surely don't want to put a lot of work into it.
> 
> So I'd like an FFI, but one that's really cheap to design/implement.
> 
> The main purpose of an FFI, as far as I'm concerned, it to make it
> possible for Emacs to use any .so library it feels, rather than only the
> ones that it was compiled with.  More specifically, so that ELPA
> packages can use such .so libraries if they feel like.
> 
> I think a "cheapish" way to do that is to make it possible for an ELPA
> package to come with a .c file that exports a "syms_of_module" function
> that can call things like defsubsr.
> 
> Installing such an ELPA package would require running a C compiler,
> obviously (unless we also provide some pre-compiled versions for
> particular target systems?).  And we'd need to add some function that
> can load the resulting compiled object (along with the .so libraries it
> depends on, since in many cases the whole purpose would be to call
> functions in those .so libs).

I really don't like this idea. You either force users to have the Emacs
headers, Emacs import library, and a C compiler available to install a
package or you provide pre-compiled binaries for popular platforms and
create an ABI versioning nightmare. The routines declared in lisp.h do
not form stable interface. Sure, you could require that libraries export
a version number, then have Emacs refuse to load libraries compiled with
the wrong ABI version, but then you have to ship many different
pre-compiled binaries and take care to bump the ABI version when necessary.

I'd definitely prefer something libffi-based and with a CFFI-like interface.