emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs-dynamic-module in Emacs Git?


From: Eli Zaretskii
Subject: Re: emacs-dynamic-module in Emacs Git?
Date: Tue, 02 Dec 2014 05:40:36 +0200

> From: Stephen Leake <address@hidden>
> Date: Mon, 01 Dec 2014 16:58:21 -0600
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >
> >> >   . It seems to me that the modules call functions implemented by
> >> >     Emacs, like make_number and Fmember, on the assumption that
> >> >     calling any Emacs function will "just work".  This is false for
> >> 
> >> I had to add a linker flag to expose every symbol of Emacs. See the
> >> relevant commit:
> >> 
> >> http://git.savannah.gnu.org/cgit/emacs.git/commit/configure.ac?h=dynamic-modules&id=5c710fba15e0a3a2ae5d831e5cdb555332238752
> >
> > I don't think this is correct: we don't really want to export all the
> > symbols.
> 
> Why not?

Security: you don't want to expose all of the Emacs bowels to any
external program out there.

Or ask yourself why the latest GCC and Binutils default to not export
anything, contrary to what they did in older versions.

> If we were writing this code to be included in Emacs core, we'd have
> access to all of the symbols.

You can have access to symbols via specific protocols without
exporting everything.  And I'm not sure you really do need access to
everything.

> _if_ the module author wants to be somewhat isolated from Emacs changes,
> and/or support more than one Emacs version, then they will want to stick
> to some stable subset. But I don't think we can define that subset ahead
> of time, and it will certainly be a different subset for each module.
> 
> We don't have a single .el file that defines the "Emacs core elisp API
> for packages"; I don't think we can define a .h file for modules either.

You are just re-iterating my doubts about usability and wisdom in this
feature.

> > All this is pretty standard practice on Windows and works well, the
> > only issue for us is to decide which functions to export (unless we
> > really want to export all of them, in which case the --export-dynamic
> > linker switch is all that's needed).
> 
> Let's make it simple; export all of them.

The other alternative is also simple; see GNU Make for an example.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]