From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Elias_M=C3=A5rtenson?= Newsgroups: gmane.emacs.devel Subject: Re: How to ship native modules? Date: Tue, 21 Feb 2017 00:01:26 +0800 Message-ID: References: <83a89gq3us.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114402c042f3bc0548f860b7 X-Trace: blaine.gmane.org 1487606579 5017 195.159.176.226 (20 Feb 2017 16:02:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Feb 2017 16:02:59 +0000 (UTC) Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 20 17:02:49 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 1cfqQK-0000IV-6F for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 17:02:48 +0100 Original-Received: from localhost ([::1]:39435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfqQP-00044j-N5 for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 11:02:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfqP5-00041W-NN for emacs-devel@gnu.org; Mon, 20 Feb 2017 11:01:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfqP4-0004JK-EH for emacs-devel@gnu.org; Mon, 20 Feb 2017 11:01:31 -0500 Original-Received: from mail-vk0-x230.google.com ([2607:f8b0:400c:c05::230]:34127) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cfqP2-0004J1-I3; Mon, 20 Feb 2017 11:01:28 -0500 Original-Received: by mail-vk0-x230.google.com with SMTP id r136so64278658vke.1; Mon, 20 Feb 2017 08:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bjRbERwKufpnOAxpUfihFl+LDMFXvrQBCVzDWO3oGjU=; b=Gg2imfOugdynzM91M8I9MoH8F/if5rSsW4Q1iYOMe+XSSs2+hYJ7QgPHTDE0md6f1X 5kEYJPeZmQe9itjEq23Xu8A9fpXOsQl7EHH5nk/ppyokQq+CodXg6l/PRITQLynFQmFp /0d2KF5d0vBY/l1ZMTo0lLlgkh64mczd5SffN/krRbHJTJhE3awrUaSC7QC5ocuaESay IYxPUrZ4p/3pmqRjA9029WwR1MY2jZ56OVR1mvZ+iG08vmq1xCPCWSQvuyQ3fNoLcBSS 7OuzRPqQIUTDZ9xsfG+vyaRUjETJg5KggHQv9h5SBRK2ekRUmjbyR/gOUFPY1fmmpbR8 Swhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bjRbERwKufpnOAxpUfihFl+LDMFXvrQBCVzDWO3oGjU=; b=rRfx4ZFTZCDt+h+1P4FifSrzbuhR0NO9arawIto7xmvVGb/UMdKeHVnVYw9GEVYF5w 9yphvfBoTllx1ReqEJr9cvjEhjzONXzMYHuG42rbWe+Tq4bjMCM6hnZyMQGHHsSy9viZ OiVZq+bsbHfImjmpxAFp6hSKKlyr+Ohq1iSZTuv1/prBoa5RXM8kyOsjIwtPrK+aiJXX 9Me0vCHAqagmmgNWl2hPpGENotSIEiAhUiVoQgWeV+8QnviS3laqlszWV1mi/F/28vE9 5qodEzzt2E4lxTStZr0Tts+rHYBZze55HA0DRr4ihWU1cOSPsdep1nvkpZlEKortp4Lw 7tOQ== X-Gm-Message-State: AMke39nb7VxjTPvNTuZIo+JqVLOf7xGAbi7NLy3IA+WXYZs+7CV3ckX08obVPMsITXc+gNpaua22Pyij4X9RsQ== X-Received: by 10.31.52.193 with SMTP id b184mr9725417vka.156.1487606487640; Mon, 20 Feb 2017 08:01:27 -0800 (PST) Original-Received: by 10.103.119.5 with HTTP; Mon, 20 Feb 2017 08:01:26 -0800 (PST) In-Reply-To: <83a89gq3us.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::230 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:212490 Archived-At: --001a114402c042f3bc0548f860b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20 February 2017 at 23:27, Eli Zaretskii wrote: > > From: Elias M=C3=A5rtenson > > 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 --001a114402c042f3bc0548f860b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 0 February 2017 at 23:27, Eli Zaretskii <eliz@gnu.org> wrote:
=
> From: Elias M=C3=A5rtenson <lokedhs@gmail.com>
> 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 compl= icated, 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 t= hrough
all the trouble of using the emacs-modules machinery.
=
Are you suggesting that I port the GSS module to use the nat= ive Emacs internal API's? If I do that, would you accept that into Emac= s proper?

Personally, I'd definitely prefer to= not have to rely on a loadable module for this kind of functionality. I gu= ess 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 a= s 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, compil= e 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 autoc= onf".=C2=A0 Your
Lisp code should just (load "foo"), and leave it to the user and<= br> package.el to put the compiled module where Emacs will find it (along
load-path).=C2=A0 Am I missing something?

I'd expect the user to run M-x package-installl gss, and then have w= orking GSSAPI support in Gnus. Currently, ELPA doesn't have any facilit= ies to support compilation of native modules as part of ELPA package instal= lation.

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 w= ould work, but that doesn't seem to be the most ideal user interface.
=C2=A0
If the package is on EL= PA, IMO it should provide a separate .el file
with a feature that Gnus will 'require', given some defcustom.
<= /blockquote>

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

Regards= ,
Elias
--001a114402c042f3bc0548f860b7--