[Top][All Lists]

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

Re: emacs-dynamic-module in Emacs Git?

From: Stephen Leake
Subject: Re: emacs-dynamic-module in Emacs Git?
Date: Mon, 01 Dec 2014 16:58:21 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt)

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?

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

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

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

However, previous posts have identified some C functions that should
_not_ be called by modules, so perhaps we need an "module_anti_api.h"
that #defines those to throw a compilation error.

-- Stephe

reply via email to

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