Quantcast

How to ship native modules?

classic Classic list List threaded Threaded
92 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to ship native modules?

Elias Mårtenson
As I am working on making the Gnus-GSS support ready for general consumption, I need to know how this thing should be distributed.

Right now there are two separate issues, with the second dependent on the first:

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.

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.

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.

How should I continue with this?

Regards,
Elias
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Eli Zaretskii
> From: Elias Mårtenson <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Aurélien Aptel-2
In reply to this post by Elias Mårtenson
On Mon, Feb 20, 2017 at 11:00 AM, Elias Mårtenson <[hidden email]> wrote:
> How should I continue with this?

As you probably already know, there are no official ways to ship
native modules at the moment (see previous discussions here [1] and
here [2]).

1: http://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00245.html
2: http://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00572.html

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Elias Mårtenson
In reply to this post by Eli Zaretskii
On 20 February 2017 at 23:27, Eli Zaretskii <[hidden email]> wrote:
> From: Elias Mårtenson <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Eli Zaretskii
> From: Elias Mårtenson <[hidden email]>
> Date: Tue, 21 Feb 2017 00:01:26 +0800
> Cc: emacs-devel <[hidden email]>
>
>  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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Elias Mårtenson
On 21 February 2017 at 00:30, Eli Zaretskii <[hidden email]> wrote:
> From: Elias Mårtenson <[hidden email]>
> Date: Tue, 21 Feb 2017 00:01:26 +0800
> Cc: emacs-devel <[hidden email]>
>
>  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‍-‍x package‍-‍install 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‍-‍lisp requires root. Can I put it somewhere in $HOME/.emacs.d?

Regards,
Elias
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Eli Zaretskii
> From: Elias Mårtenson <[hidden email]>
> Date: Tue, 21 Feb 2017 10:48:03 +0800
> Cc: emacs-devel <[hidden email]>
>
>  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.

Really?  I was under the impression that one would need to install the
Kerberos libraries from http://web.mit.edu/kerberos/dist/, and then
have the GSSAPI library built for Windows.  These all don't seem to be
available out of the box on MS-Windows.  Am I missing something?

>  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‍-‍x package‍-‍install process.

I think that making package.el be able to compile programs in
languages like C is an ambitious goal that is best left to end users
at this stage.  For simple enough modules, the Makefile can be made
small and portable, so IMO it isn't worth the complexity to do more
than that, at least not yet.

> Installing in site‍-‍lisp requires root. Can I put it somewhere in $HOME/.emacs.d?

Yes, like we do with Lisp packages.  A module can live anywhere a Lisp
package can live, in order for Emacs to find it.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Elias Mårtenson
On 21 February 2017 at 11:41, Eli Zaretskii <[hidden email]> wrote:
 
> 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.

Really?  I was under the impression that one would need to install the
Kerberos libraries from http://web.mit.edu/kerberos/dist/, and then
have the GSSAPI library built for Windows.  These all don't seem to be
available out of the box on MS-Windows.  Am I missing something?

Yes, I was a bit hasty. If you want to use the standard C API, then you need those libraries. However, you could use the Windows API, SSPI instead. It implements the same functionality using a different API (because of course they do).

Note that I don't have any intention of implementing SSPI support myself, but implementing an SSPI backend would not be terribly difficult.
 
I think that making package.el be able to compile programs in
languages like C is an ambitious goal that is best left to end users
at this stage.  For simple enough modules, the Makefile can be made
small and portable, so IMO it isn't worth the complexity to do more
than that, at least not yet.

Fair enough.

That leave me with only one question: With the main user of this functionality being Gnus, should GSS support be implemented as part of Emacs proper, or shipped using ELPA?

The pros and cons of each approach should be well understood now, and I'm willing to implement it either way. So we're up to a policy decision on the part of the Emacs maintainers now.

Regards,
Elias
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Andreas Politz, INF|INF-I-2
In reply to this post by Elias Mårtenson
Elias Mårtenson <[hidden email]> writes:

> 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.

Hi, I am the author of pdf-tools and I have a very similar, if not the
same, problem.

I think your analogy to autoconf is not the right one.  What's needed is
more like an abstraction over the various systems including package
manager and possibly naming schemes.  For example on Arch you need to
install the package krb5 with pacman, while on Debian its probably
libkrb5-dev and libkrb5 using aptitude and on Windows you'd download
some installer or whatever.

There are various other details to consider. For example make is called
gmake on BSD, or you need to setup an environment variable
(e.g. PKG_CONFIG_PATH on macos).

This could be implemented in a neat, small package, your package depends
on and calls into as part of the installation or first-time-running
process.

Adding a new system-configuration should be fairly easy.

I've been pondering to write such a thing,

what do you think ?

-ap



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Elias Mårtenson
On 21 February 2017 at 12:50, Andreas Politz <[hidden email]> wrote:
Elias Mårtenson <[hidden email]> writes:

> 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.

Hi, I am the author of pdf-tools and I have a very similar, if not the
same, problem.

I use pdf-tools, and I have definitely seen the same issue there.
 
I think your analogy to autoconf is not the right one.  What's needed is
more like an abstraction over the various systems including package
manager and possibly naming schemes.  For example on Arch you need to
install the package krb5 with pacman, while on Debian its probably
libkrb5-dev and libkrb5 using aptitude and on Windows you'd download
some installer or whatever.

Indeed. The MIT and Heimdal implementations also have some minor differences that has to be taken into account, making the Makefile more complex.
 
There are various other details to consider. For example make is called
gmake on BSD, or you need to setup an environment variable
(e.g. PKG_CONFIG_PATH on macos).

I don't use OSX much anymore, so I wasn't aware of that.
 
This could be implemented in a neat, small package, your package depends
on and calls into as part of the installation or first-time-running
process.

Adding a new system-configuration should be fairly easy.

I've been pondering to write such a thing,

what do you think ?

I think that sounds like a great idea. If you build a prototype I'd be happy to provide whatever assistance I can.

Regards,
Elias 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Andreas Politz, INF|INF-I-2
Elias Mårtenson <[hidden email]> writes:

> I think that sounds like a great idea. If you build a prototype I'd be happy to provide whatever assistance I can.

Great, I'll get back here, if I have something working.

-ap

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Stefan Monnier
In reply to this post by Eli Zaretskii
> You can provide a small Makefile that the user will have to invoke in
> order to compile the C source.

The user doesn't even have to invoke it: package-install can invoke it
(indirectly) by having something akin to

    (eval-when-compile (shell-command "make"))

in one of the Elisp files.


        Stefan


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Elias Mårtenson
On 21 Feb 2017 11:24 PM, "Stefan Monnier" <[hidden email]> wrote:
> You can provide a small Makefile that the user will have to invoke in
> order to compile the C source.

The user doesn't even have to invoke it: package-install can invoke it
(indirectly) by having something akin to

    (eval-when-compile (shell-command "make"))

in one of the Elisp files.

I thought ELPA packages could only contain el files? (granted, even if that is the case, I could always encode the C code in elisp code, but that's a bit ugly) 
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Eli Zaretskii
In reply to this post by Elias Mårtenson
> From: Elias Mårtenson <[hidden email]>
> Date: Tue, 21 Feb 2017 12:13:44 +0800
> Cc: emacs-devel <[hidden email]>
>
> That leave me with only one question: With the main user of this functionality being Gnus, should GSS
> support be implemented as part of Emacs proper, or shipped using ELPA?
>
> The pros and cons of each approach should be well understood now, and I'm willing to implement it either
> way. So we're up to a policy decision on the part of the Emacs maintainers now.

I looked at the C source.  It's quite small, and if reimplemented as
part of Emacs, will be even smaller (no need to reinvent XCAR, intern,
etc.).  So I see no problems with adding this to the Emacs sources,
probably as a separate C file.

John?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Eli Zaretskii
In reply to this post by Stefan Monnier
> From: Stefan Monnier <[hidden email]>
> Date: Tue, 21 Feb 2017 09:44:39 -0500
>
> > You can provide a small Makefile that the user will have to invoke in
> > order to compile the C source.
>
> The user doesn't even have to invoke it: package-install can invoke it
> (indirectly) by having something akin to
>
>     (eval-when-compile (shell-command "make"))
>
> in one of the Elisp files.

Yes, of course.  Provided that the 'make' doesn't need any
command-line options that only human can deduce (depends on how clever
and reliable the Makefile is).

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Stefan Monnier
In reply to this post by Elias Mårtenson
> I thought ELPA packages could only contain el files? (granted, even if that
> is the case, I could always encode the C code in elisp code, but that's a
> bit ugly)

No, they can contain any file you like (they're just tarballs).
Some commonly used non-Elisp files are image files and .info files, but
C files will work just as well (tho package.el knows nothing about them).


        Stefan


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

Göktuğ Kayaalp
In reply to this post by Elias Mårtenson
> (eval-when-compile (shell-command "make"))

Mind that this can cause problems in a system where ‘make’ points to
sth. else than GNU Make, e.g. on BSDs it's bmake.  I'd rather have

(defconst my-module-C-extensions-compiled-p
  (= 0
     (eval-when-compile (shell-command (or (executable-find "gmake")
                                           "make")))))

but maybe it would be better to introduce some standard machinery for
native modules (at least for those in C) early on that later the
community won't have to deal with fragmentation over different ad-hoc
systems.  At least a standard way to define how to build the module
would be nice:

(define-dynamic-module example
  :path "/path/to/module"
  :compile-method gnu-make)

;; (build-dynamic-module 'example)

That can be included in NAME-pkg.el for packaging and distributing
modules (or maybe define-package may be extended for building dynamic
modules of a package).  Certain make recipes like ‘all’ and ‘test’ may
be required.

Regards,
-gk.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to ship native modules?

John Wiegley
In reply to this post by Eli Zaretskii
>>>>> Eli Zaretskii <[hidden email]> writes:

> I looked at the C source. It's quite small, and if reimplemented as part of
> Emacs, will be even smaller (no need to reinvent XCAR, intern, etc.). So I
> see no problems with adding this to the Emacs sources, probably as a
> separate C file.

> John?

Sure, I'm fine with that being in core.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

request to reconsider libnettle/libhogweed (was: How to ship native modules?)

Ted Zlatanov
In reply to this post by Eli Zaretskii
On Tue, 21 Feb 2017 12:06:40 -0800 John Wiegley <[hidden email]> wrote:

JW> Sure, I'm fine with [GSSAPI] being in core.

Hi, John, Eli, and everyone else. It's been a few years since I've
brought up the libnettle/libhogweed topic and we've had lots of change
in the C core and in our community.

Since it's apparently OK to add the GSS/Kerberos linkage to the core, I
want to ask again that the libnettle/libhogweed crypto functions be
allowed in the core, for the following reasons:

* they are more *generally* useful than GSS and will enable future
  development in many directions. (I'm not saying GSS is not useful,
  just that it's a more specific tool that serves a narrow purpose.)

* we already link to GnuTLS, which means those C functions are available
  already. So this is not going to require much extra C code, just some
  work to expose the C functions. My original patch, now many years old,
  can probably be adapted or rewritten pretty easily. Most of it was
  tests. Keeping up to date is similarly easy as long as users keep up
  to date with GnuTLS. Note also that on the Lisp side, no low-level
  crypto code will be written or maintained, we're only exposing
  libraries that are maintained and reviewed by an existing large
  community.

* recall that Stefan, the maintainer at the time, asked me to push for a
  module approach with the understanding that the crypto module would be
  distributed to let users and packages access those functions. We now
  have a module system, but there has been no support or interest in
  implementing a module *distribution* system that would allow users to
  access those cryptographic functions with a stock distribution of
  Emacs. Instead all the comments have been that it's a hard problem and
  the Emacs developers would rather not deal with it. Where the comments
  have suggested a solution, it has been "let them run make" which
  rhymes with "let them eat cake."

* personally, I would rather make the core more functional out of the
  box, so my proposal is to go back to the original C patch instead of
  inventing a module distribution system. (A module distribution system
  may yet make sense, and I have nothing against it, but I don't want to
  wait more years for it or invent it.)

Thank you for your consideration.
Ted


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: request to reconsider libnettle/libhogweed

Stefan Monnier
>   Emacs. Instead all the comments have been that it's a hard problem and
>   the Emacs developers would rather not deal with it.  Where the comments
>   have suggested a solution, it has been "let them run make" which
>   rhymes with "let them eat cake."

Hmm... I'm sorry if that's how I'm coming across.  But that's really not
my intention.  Instead, what I mean is:
- I don't personally know exactly what is needed (I have some vague
  idea, but details matter here).
- We probably want to have a solution *now* and that basically means
  using something like the eval-when-compile+make hack.

But indeed, it looks like the new maintainers, being OK with adding
GSSAPI in the core, will be OK with adding random other libs to the
core, so the pressure to improve the dynload module infrastructure will
be low.


        Stefan


12345
Loading...