Re: FFI again

[Stephen J. Turnbull]

Andy Moreton writes:
 > On Mon 07 Oct 2013, Stefan Monnier wrote:
 > 
 > > So what I propose is to use "runtime loading of DSO" as a poor man's FFI
 > > where the DSL of the FFI is C and where the compilation of this "DSL" is
 > > handled by a C compiler.
 > >
 > > The only technical difference between what I propose and typical "runtime
 > > loading of DSOs" is that the system also handles running the C compiler,
 > > so you can download the TedZ-OpenPGP package from ELPA and install it
 > > (provided you have a C compiler on your machine).
 > 
 > This will work well enough for POSIX systems,

And in XEmacs, it has worked well enough for a decade now.  Windows,
too.  But very few users actually use it as far as I know, on either
type of system.

 > but will fail miserably on Windows systems. Most Windows users do
 > not develpment tools installed, and would have a hard time to find
 > a C compiler producing binaries with the correct ABI, and the other
 > required build tools and dependencies.

You don't need to worry about such users.  The XEmacs runtime DLL
loading system demonstrated optional static linking of the wrapper
code, and load the external DLL as usual at program execution.  The
wrapper code does an Fprovide at Emacs initialization, so the feature
code works as expected.  The price is a somewhat fatter binary and
perhaps loading an external library that would otherwise not take up
any memory.  No DDL wrapper, no problem for users.

Even if the necessary "stuff" is available, such a DLL loading system
really isn't very useful to ordinary users.  Almost nobody except
developers[1] who can save a lot of time by recompiling the module
only and then reloading to test really benefit (having done 3 of these
myself, I can say it *is* a nice feature), vs building the feature
into the Emacs binary.  If you're only occasionally going to rebuild
modules with a C compiler, it's not so much of additional burden to
rebuild Emacs as well.  If the necessary stuff *isn't* available then
you're dependent on somebody else to build an installer.  Again, these
days it may as well be all of Emacs as a single module (and quite
likely the corresponding external DLL).  That way the user doesn't
even need to put the DLLs in the right place.


Footnotes: 
[1]  The others are those who just love BrightShinyThings.