Re: GnuTLS for W32

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 04 Jan 2012 12:45:47 +0900
> Cc: emacs-devel@gnu.org
> 
> Óscar Fuentes writes:
> 
>  > If, at run time, you can find the elisp packages downloaded by
>  > package.el, what's the problem with finding a dll on the same directory
>  > (or a subdirectory of it, if you wish) ?
> 
> None, AFAICS.  That's (actually, a sibling directory) is what XEmacs
> does[1], and what Python does (same directory, if desired).

Please don't say that without telling the details.  There are people
reading this thread who don't know enough about Windows and are likely
to take this at face value.

Once again: the way the current C code is written, Emacs _cannot_ load
DLLs except from directories which Windows searches for dynamic
libraries.  Those directories do not include load-path, and therefore
no amount of coding in package.el alone will be able to make
package.el usable for downloading and installing DLLs (even if we
resolve the issue of doing so from within a running Emacs session).
Changes on the C level are needed to make that possible; but if we are
going to make C-level changes, it would be much better to have DLL
downloaded to the same directory where emacs.exe lives or (if the user
so wishes) to some directory on PATH, because that's where DLLs are
normally located.

An alternative is to modify PATH to include site-lisp or some other
directory on load-path, but that is a much worse idea, and it cannot
be done from a running Emacs session anyway.

> [1]  Except that we don't provide DLLs for download, for various
> reasons, the most important of which is that binary distributions are
> bug magnets that distract the maintainers disproportionately, and
> non-maintainers are generally unwilling to touch.

That point was made in this thread more than once, but Ted is still
pushing for it.  Which is fine by me, assuming that someone will step
forward and do the job.