Re: persistent data feature

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, luangruo@yahoo.com, 
> tom@logand.com, emacs-devel@gnu.org
> Date: Thu, 16 Dec 2021 06:10:30 +0100
> 
> Le merkredo, 15-a de decembro 2021, 17-a horo kaj 44:09 CET Stefan Monnier 
> a écrit :
> > > That would be cool.  That would make “canonical” extensions more akin
> > > to users’ one, and would reduce the gap between user hacking and
> > > standard development (akin to the “absence of keywords” of lisp, and
> > > to the fact users’ extensions can look like core features), encourage
> > > hacking, and equality of emacs’ hackers.
> > > 
> > > Plus I like the idea you can install libraries separatly from the end
> > > software, before or after, and remove them at wish.
> > 
> > That was my original intention when I pushed for the addition of
> > loadable modules.  I suspect we need to significantly improve our
> > loadable module support before it can become reality.
> > 
> > In the mean time, maybe we could try and make the non-w32 world use
> > a similar approach to the one used in the w32 code, so support for
> > sqlite/gnutls/whathaveyou is compiled-in but Emacs still works
> > properly if the .so is missing at run-time.
> 
> oh yes indeed it would be very cool! plus doesn’t gnu and especially emacs 
> has some sort of policy saying we shouldn’t support some feature on 
> proprietary systems and not on free ones? granted here it’s minor (because 
> we already have fully working package managers on free systems while 
> windows more need this as it doesn’t, but still, that’s a robustness 
> characteristic)

I don't object to make the shared-library loading be dynamic, of
course.  It should be easy to do so by utilizing the existing
WINDOWSNT code with minimal changes.

However, please note that doing this on Posix systems is much less
useful than on MS-Windows, for 2 main reasons:

  . unlike MS-Windows, on Posix systems Emacs will start with no
    problems when an optional shared library is missing; it is only
    when some function from the library is called that you'll have
    trouble (Emacs will segfault);

  . unlike on MS-Windows, users of Posix systems who don't build their
    own Emacs generally install a prepackaged binary distribution, and
    that always makes sure the dependencies, in the form of those
    optional shared libraries, are also installed

So the gains are much smaller, and basically, AFAICT, are only of the
aesthetic nature, because the Emacs memory footprint is unaffected by
the optional library either way, unless the user uses stuff like
LD_PRELOAD.

This is why we didn't do on Unix what we do for w32.  It could be that
just arranging for the relevant FOO-available-p function to return nil
on Posix systems would be enough to prevent the crashes when the
library is missing, which is currently the only real, albeit rare,
problem with this.

That said, if someone submits patches for using the dynamic loading on
Unix and GNU systems, I won't object, of course.