[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.
signature.asc
Description: OpenPGP digital signature
- Re: FFI again, (continued)
- Re: FFI again, Stephen J. Turnbull, 2013/10/07
- Re: FFI again, Stefan Monnier, 2013/10/07
- Re: FFI again, Andy Moreton, 2013/10/07
- Re: FFI again, Stefan Monnier, 2013/10/07
- Re: FFI again, Eli Zaretskii, 2013/10/08
- Re: FFI again, Stephen J. Turnbull, 2013/10/07
- Re: FFI again, Richard Stallman, 2013/10/07
- Re: FFI again, Stephen J. Turnbull, 2013/10/08
- Re: FFI again, Eli Zaretskii, 2013/10/08
Re: FFI again, Eli Zaretskii, 2013/10/05
Re: FFI again,
Daniel Colascione <=
Re: FFI again, Richard Stallman, 2013/10/06