Re: emacs-dynamic-module in Emacs Git?

[Eli Zaretskii <eliz@gnu.org>]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Wed, 26 Nov 2014 21:10:31 -0500
> 
> I've pushed your dynamic-modules branch (rebased against today's master
> branch) to the dynamic-modules branch on the Emacs repo for review and
> testing.

Thanks (to both of you).

> There are just a few issues, none major:

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.

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

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

    (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?)

  . I don't understand why load-module-suffixes includes extensions
    from different platforms, nor why is this variable needed at all.
    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?

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.