emacs-devel
[Top][All Lists]
Advanced

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

Re: How to ship native modules?


From: Elias Mårtenson
Subject: Re: How to ship native modules?
Date: Tue, 21 Feb 2017 00:01:26 +0800

On 20 February 2017 at 23:27, Eli Zaretskii <address@hidden> wrote:
> From: Elias Mårtenson <address@hidden>
> Date: Mon, 20 Feb 2017 18:00:24 +0800
>
> The first issue is that I have no idea how to actually distribute the native GSSAPI module. It's just a single,
> reasonably small, C file that needs to be compiled with the libgssapi_krb5.so library. If this is bundled in
> Emacs proper, making it a part of the build system isn't too complicated, although I don't believe this has been
> done before.

IMO, it makes little sense to distribute loadable modules with Emacs
itself: if they are part of the standard distribution, they should
just be "normal" source files in src/, and don't have to go through
all the trouble of using the emacs-modules machinery.

Are you suggesting that I port the GSS module to use the native Emacs internal API's? If I do that, would you accept that into Emacs proper?

Personally, I'd definitely prefer to not have to rely on a loadable module for this kind of functionality. I guess the only drawback is that most distributions won't ship Emacs with GSS support, since that required the gssapi libraries to be available.

What is the best solution here?

> If it is to be shipped as part of ELPA, then a different question emerges: Should I simply add code to the Elisp
> files that checks if it can find the native library and if not, compile it on the fly? It's doable, but I'd hard to
> reinvent several wheels to do so. Essentially I'd have to rebuild part of autoconf in Elisp.

I'm not sure I see the reason for "rebuilding part of autoconf".  Your
Lisp code should just (load "foo"), and leave it to the user and
package.el to put the compiled module where Emacs will find it (along
load-path).  Am I missing something?

I'd expect the user to run M-x package-installl gss, and then have working GSSAPI support in Gnus. Currently, ELPA doesn't have any facilities to support compilation of native modules as part of ELPA package installation.

Are you suggesting that the user manually download the C part of the "gss" package and compile it, and then run "emacs -L path/to/custom/libs" when they start Emacs? That would work, but that doesn't seem to be the most ideal user interface.
 
If the package is on ELPA, IMO it should provide a separate .el file
with a feature that Gnus will 'require', given some defcustom.

Fair enough. That can be done with a relatively minor patch to nnimap.el. However, it still leaves the issue of how to deal with the native module part of this.

Regards,
Elias

reply via email to

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