Re: How to ship native modules?

[Elias Mårtenson]

On 21 February 2017 at 00:30, Eli Zaretskii <address@hidden> wrote:

> From: Elias Mårtenson <address@hidden>
> Date: Tue, 21 Feb 2017 00:01:26 +0800
> Cc: emacs-devel <address@hidden>
>
>  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 the module is to come with Emacs out of the box, yes.

Since the main beneficiary of this feature is Gnus, it does make sense.

 

> If I do that, would you accept that into Emacs proper?

I don't know, I'd have to look at the sources first.

It's not that much work to implement the C part of this. I'll have to get acquainted with the internal Emacs API's and then do the implementation. Hopefully it should be a non-controversial thing to include.

 

> 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.

Is it different from any other optional library in any significant
way?  E.g., GPM or the image libraries?  They all require to have the
library installed for Emacs to be able to be built with its support.

Technically, it's the same thing. The difference is that most people don't have the krb5 packages installed, and enabling the GSS feature would require packagers to add another dependency to Emacs, giving them two alternatives: 1) Not include GSS in their prebuilt version of Emacs, or 2) add another dependency to Emacs, resulting in another package being installed with it.

Now, krb5 is not a big library, so option 2 above is IMHO the right way to go, but I worry that packagers won't see it that way and we'll end up with a feature that users would have to rebuild their Emacs to use.

However, there is an upside. Most people who need this feature are in corporate environments, usually on Windows (Kerberos is the standard authentication mechanism in Active Directory) and the runtime libraries are a standard part of Windows, so at on that platform there is no issue.

 

> 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.

You can provide a small Makefile that the user will have to invoke in
order to compile the C source.  Same as in modules/mod-test/ in the
Emacs sources.

I could, and I'd have to. But it would be very nice if this could be part of the M‍-‍x package‍-‍install process.

If it was, then going the ELPA route is definitely the best way.

 

Compile: yes (except that I see no reason for downloading manually, it
can all come to the end-user machine when the package is installed).
But I see no reason to run Emacs specially: if the Makefile has an
'install' target that puts the compiled module in site-lisp, Emacs
will find it when some Lisp attempts to load it.

Installing in site‍-‍lisp requires root. Can I put it somewhere in $HOME/.emacs.d?

Regards,

Elias