[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FFI again

From: Daniel Colascione
Subject: Re: FFI again
Date: Sat, 05 Oct 2013 16:24:03 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

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.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]