Re: FFI again

[joakim@verona.se]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 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).
>
> It's not ideal, but it should be reasonably cheap to implement, and
> would let people get access to pretty much any library they want.

Whats wrong with libffi?
http://sourceware.org/libffi/

Its what everyone else uses, including Guile, Xwidgets, and the existing
Emacs FFI patches.

>
>
>         Stefan
>

-- 
Joakim Verona