Re: Emacs ffi

[Andrea Corallo <acorallo@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
>> Date: Thu, 15 Aug 2024 05:31:49 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The way we do it when loading modules requires the _loaded_ library to
>> > declare itself compatible, by exporting a symbol of a certain name.
>> > That is an action by the library we load, not by the Lisp program
>> > which loads it.
>> 
>> But we could do the same for our hypothetical ffi machinery, that is:
>> `define-ffi-library' could fail if the shared library is not exporting
>> the predetermined symbol we expect no?
>
> Of course.  But how many such libraries do that?

Dunno, ATM very few if not zero I guess.

> You are in effect
> talking about libraries specifically written or adapted for this
> hypothetical FFI machinery that is Emacs- or at least GNU-specific.
> Whereas the main motivation behind the request is to allow loading
> arbitrary libraries out there that already exist and definitely don't
> export any such symbols.  At the very least, the interested individual
> will have to fork the library, verify it has a GPL-compatible license,
> modify its code to export such a symbol, and then rebuild it.

Maybe over time libraries interested to e used by Emacs could accept the
simple patch necessary to define end export the symbol?

> So, while this arrangement is definitely possible and okay for Emacs,
> I very much doubt that it will be practical enough to be of use.
> Nevertheless, if someone submits such an implementation of such FFI
> machinery, I see no obstacles to accepting it (except the usual: clean
> code, good documentation, etc.).


Okay thanks, we are on the same page on this.


  Andrea