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 17:27:55 +0200 Message-ID: <83a89gq3us.fsf@gnu.org> References: 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 1487605569 8239 195.159.176.226 (20 Feb 2017 15:46:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Feb 2017 15:46:09 +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 16:46:02 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 1cfqA5-0001H3-O8 for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 16:46:02 +0100 Original-Received: from localhost ([::1]:39306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfqA9-00066S-K3 for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 10:46:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfps6-0006TG-CL for emacs-devel@gnu.org; Mon, 20 Feb 2017 10:27:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfprz-0000wZ-Qb for emacs-devel@gnu.org; Mon, 20 Feb 2017 10:27:23 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfprz-0000wV-N2; Mon, 20 Feb 2017 10:27:19 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4787 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cfprz-0006m0-2v; Mon, 20 Feb 2017 10:27:19 -0500 In-reply-to: (message from Elias =?utf-8?Q?M=C3=A5rtenson?= on Mon, 20 Feb 2017 18:00:24 +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:212487 Archived-At: > From: Elias Mårtenson > 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. > 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? > The second issue is how to ship my changes to Gnus. My changes are limited to a changes to nnimap.el, but > this new feature will now try to require the ‘gss’ feature when gssapi authentication is enabled. If the gssapi > library is shipped as part of ELPA, then we end up with the interesting situation where the packaged version > of Gnus depends on a package in ELPA. If the package is on ELPA, IMO it should provide a separate .el file with a feature that Gnus will 'require', given some defcustom. Thanks.