Re: emacs-dynamic-module in Emacs Git?

[Aurélien Aptel]

On Sat, Nov 29, 2014 at 6:05 PM, Eli Zaretskii <address@hidden> wrote:
> I have a few more, specific to the Windows build:
>
>   . As with other optional libraries, using libltdl should detect its
>     availability at run time, and load it dynamically, instead of
>     passing -ltdl switch to the linker when Emacs is built.  See
>     examples of how to do that in image.c and gnutls.c.

What's the point of doing it this way? Honest question.

>   . The Makefile's use literal .so extension for the dynamic libraries
>     being built -- this is non-portable and should be determined at
>     configure time.

The makefile is temporary. It can be replaced by a more portable
script or elisp afterwards.

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

>     Windows (the link command that produces the shared object will
>     fail), unless we mark such exportable functions and build an
>     import library that will be passed to the linker when the module's
>     shared object is built.  Likewise with global variables defined by
>     Emacs.

I've never used Windows much for developement. Isn't there a similar
flag we can use on mingw?

>     (In general, I question why "modules" that require such tight
>     integration with Emacs internals are a good idea: why not simply
>     add them to the Emacs core and be done with that?  What do we gain
>     by having them as separate .so shared objects?)

We could directly add them to Emacs I guess... It's just that time has
shown no-one actually agrees to do it.

>   . I don't understand why load-module-suffixes includes extensions
>     from different platforms, nor why is this variable needed at all.

`load' has complex logic based on suffixes and knowing the type of
files based on them. I tried to re-use what I could without risking
breaking something.

>     AFAIK, libltdl is perfectly capable of finding shared objects on
>     each platform without us feeding it the extension to use.  It
>     knows what extensions are used by the underlying platform for
>     shared libraries.  Moreover, trying to load .dylib or .dll on
>     GNU/Linux will hardly produce good results, so why risk that by
>     exposing the platform-specific extensions at all?

I've never had other shared libraries than my system native ones,
especially in an emacs related dir. I don't think it's a problem given
you can load a module using the full path to it.

>
> Please note that the above is based solely on examining the
> source-level diffs; I didn't yet try to build this branch or use it.
>
> Thanks again for working on this.

Thanks for the feedback :-)