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 10:48:03 +0800 Message-ID: References: <83a89gq3us.fsf@gnu.org> <8360k4q0yx.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f40304361ce8b93fa30549016814 X-Trace: blaine.gmane.org 1487645826 9087 195.159.176.226 (21 Feb 2017 02:57:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Feb 2017 02:57:06 +0000 (UTC) Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 21 03:57:01 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 1cg0dR-0001y8-9i for ged-emacs-devel@m.gmane.org; Tue, 21 Feb 2017 03:57:01 +0100 Original-Received: from localhost ([::1]:41950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cg0dX-0007VI-2N for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 21:57:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cg0Uq-0001M5-J1 for emacs-devel@gnu.org; Mon, 20 Feb 2017 21:48:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cg0Up-0004Zf-8p for emacs-devel@gnu.org; Mon, 20 Feb 2017 21:48:08 -0500 Original-Received: from mail-ua0-x233.google.com ([2607:f8b0:400c:c08::233]:34032) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cg0Un-0004ZD-6f; Mon, 20 Feb 2017 21:48:05 -0500 Original-Received: by mail-ua0-x233.google.com with SMTP id 35so75916754uak.1; Mon, 20 Feb 2017 18:48:05 -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=+uZC/HjMOc24f3pk+RGF+IAhjrH5b1P4QKZDN+VlwsM=; b=psPJk1W0wTyVj0Kf5jSXKKIpGHPoE4Rn7wTMTCsrzJGJZ8rYtahin+fnOauWpFxs4G Vz/7XRazEu47IcuEuFMVVaETNPEcFqhaV/M4hBmn9ZK05IdPLSvOTuHQM5MXOdTk+anv 3fo5dq3R5h/OsHotpCXW+KaRK3JVaJc78OpS26ip/+krAaPc6N5fIRxFXm1JV1sF/sTk zkhO1ZVs01oXggxcUP3rx0JNRkUd9gKOApxdI9yZoW+GTwz4wMefNcF2cLPf5G3xr6yh nWjD4FW1x/32Dn5CrLETiQt15zX9DI39EH543PXtdbQhggbbun4+LsMxHhjZOlbx01sG 2CyQ== 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=+uZC/HjMOc24f3pk+RGF+IAhjrH5b1P4QKZDN+VlwsM=; b=BaLRAI6VH4bXb+AJckkedaa7LcB5BA41ZVcZJIGyFhcnb97SKdeqqgO5jejxxZRuIy /6vHPf9OrlIYRz+2GqC0aBivlcdjJgEl510kIOGpZ0ug6gwzXDWhrl3aKJ3fQnTOSL+e pN9m8qfysIKGoVwRYgqRr8vGpbaLIpP0SHSmEHCNha53XFys0x/l8RIul7hEwhNwKO6q i6PksgY4kkmLFJoH0eL+doEIRRL4seKLCk5Cccl1K1RXtlVyVOge9e/Z4OffcZCuqTAD /wa2ZCxLpkvjx1aTBklQDlQ827UF6ZdQXPDNNZ98no2J+1cy090V0qWiD7fxToDIvN1a pGNw== X-Gm-Message-State: AMke39kP93j4H4YohGFYU4UzW+RM5s3hcZ9arK9zKV+/KR3Ag1KnrDuMUZ9ZQmLyDRogJBN+ZzWl6jt8avH+FQ== X-Received: by 10.176.76.68 with SMTP id d4mr12091789uag.105.1487645284314; Mon, 20 Feb 2017 18:48:04 -0800 (PST) Original-Received: by 10.103.119.5 with HTTP; Mon, 20 Feb 2017 18:48:03 -0800 (PST) In-Reply-To: <8360k4q0yx.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:c08::233 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:212509 Archived-At: --f40304361ce8b93fa30549016814 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21 February 2017 at 00:30, Eli Zaretskii wrote: > > From: Elias M=C3=A5rtenson > > 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. > 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=E2=80=8D-=E2=80=8Dx package=E2=80=8D-=E2=80=8Dinstall 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=E2=80=8D-=E2=80=8Dlisp requires root. Can I put it somew= here in $HOME/.emacs.d? Regards, Elias --f40304361ce8b93fa30549016814 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 1 February 2017 at 00:30, Eli Zaretskii <eliz@gnu.org> wrote:
=
> From: Elias M=C3=A5r= tenson <lokedhs@gmail.com> > Date: Tue, 21 Feb 2017 00:01:26 +0800
> Cc: emacs-devel <emacs-devel= @gnu.org>
>
>=C2=A0 IMO, it makes little sense to distribute loadable modules with E= macs
>=C2=A0 itself: if they are part of the standard distribution, they shou= ld
>=C2=A0 just be "normal" source files in src/, and don't h= ave to go through
>=C2=A0 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.
=C2=A0
> If I do that, would you acce= pt 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&= #39;s and then do the implementation. Hopefully it should be a non-controve= rsial thing to include.
=C2=A0
> Personally, I'd defini= tely prefer to not have to rely on a loadable module for this kind of funct= ionality. 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?=C2=A0 E.g., GPM or the image libraries?=C2=A0 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 dif= ference 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 prebui= lt version of Emacs, or 2) add another dependency to Emacs, resulting in an= other package being installed with it.

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

<= /div>
However, there is an upside. Most people who need this feature ar= e in corporate environments, usually on Windows (Kerberos is the standard a= uthentication mechanism in Active Directory) and the runtime libraries are = a standard part of Windows, so at on that platform there is no issue.
=
=C2=A0
> 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 i= n
order to compile the C source.=C2=A0 Same as in modules/mod-test/ in the Emacs sources.

I could, and I'd hav= e to. But it would be very nice if this could be part of the M=E2=80=8D-=E2= =80=8Dx=C2=A0package=E2=80=8D-=E2=80=8Dinstall process.

If it was, then going the ELPA route is definitely the best way.
=C2=A0
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<= br> will find it when some Lisp attempts to load it.

<= /div>
Installing in site=E2=80=8D-=E2=80=8Dlisp requires root. Can I pu= t it somewhere in $HOME/.emacs.d?

Regards,
Elias
--f40304361ce8b93fa30549016814--