|Subject:||Re: How to ship native modules?|
|Date:||Tue, 21 Feb 2017 10:48:03 +0800|
> 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.
> If I do that, would you accept that into Emacs proper?
I don't know, I'd have to look at the sources first.
> 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.
> 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
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
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|