From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: How to ship native modules? Date: Mon, 20 Feb 2017 18:30:14 +0200 Message-ID: <8360k4q0yx.fsf@gnu.org> References: <83a89gq3us.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1487608284 27228 195.159.176.226 (20 Feb 2017 16:31:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Feb 2017 16:31:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Elias =?utf-8?Q?M=C3=A5rtenson?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 20 17:31:21 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfqrw-0006YU-7j for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 17:31:20 +0100 Original-Received: from localhost ([::1]:39647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfqs1-0004Yu-VN for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 11:31:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfqr2-0004Xd-V5 for emacs-devel@gnu.org; Mon, 20 Feb 2017 11:30:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfqqz-0004Xt-Pn for emacs-devel@gnu.org; Mon, 20 Feb 2017 11:30:24 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfqqz-0004Xp-Nb; Mon, 20 Feb 2017 11:30:21 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4849 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cfqqy-0003Yf-Un; Mon, 20 Feb 2017 11:30:21 -0500 In-reply-to: (message from Elias =?utf-8?Q?M=C3=A5rtenson?= on Tue, 21 Feb 2017 00:01:26 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212497 Archived-At: > From: Elias Mårtenson > Date: Tue, 21 Feb 2017 00:01:26 +0800 > Cc: emacs-devel > > 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'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. 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. > 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. 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. > 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. The module should be installed in site-lisp, IMO.