Re: Adding GnuTLS to the Windows port

[Juanma Barranquero <lekktu@gmail.com>]

On Thu, Oct 7, 2010 at 09:52, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'm not sure I understand the issue well enough to say much.

The issue is quite simple:

- On the Windows port we compile support to use several libraries as
DLLs, but these libraries aren't linked to the executable (i.e.,
loading Emacs does not load them) but dynamically at first use, by
determining whether the library (the file containing it) can be found
and loaded; one reason being that our "official" binary must be able
to work whether they are available or not.

- Originally we hardcoded the filenames of the libraries, checking
each name in turn; for example, for xpm, we tried "libxmp.dll", then
"xmp4.dll", etc.

- At some point, we added an alist to associate libraries with their
candidate filenames, to make it cleaner and also user-configurable.

- For historical reasons (as all of these libraries were for image
support) the alist variable was called `image-library-alist'.

And now the issue is that it is quite likely that we'll end using the
same variable for other kinds of libraries, like libxml2, GnuTLS, and
perhaps D-BUS or others. So `image-library-alist' is no longer a good
name. All my patch does is renaming it to `dynamic-library-alist' and
keeping the old name as an obsolete alias.

Note, BTW, that all the above comes from the Windows port, but there's
nothing Windows-specific in (image|dynamic)-library-alist. Any port
that does delayed dynamic loading can benefit from it.

> The only
> point I care about, really, is that such a change be made keeping in
> mind the likely future addition of a more general support for
> dynamic loading.

I cannot comment on that, as I know nothing about the future "general
support for dynamic loading", other than the legal issues that were
commented here a while ago. Care to elaborate (or point to some old
thread I've missed)?

    Juanma