Re: GnuTLS for W32

["Óscar Fuentes" <ofv@wanadoo.es>]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Jan 4, 2012 at 15:14, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> On the topic of how hard is to load a dll from an arbitrary location,
>> that is what I found on the Emacs sources:
>
> I think Eli's already aware of that function.

He's repeating that loading a dll with a pathname would require changes
at the C level.

>> I think that Emacs is right now capable of loading a dll from an
>> arbitrary place. Just set dynamic-library-alist as it contains ('gnutls
>> . "/path/to/gnutls/gnutls.dll") (or whatever are the right names).
>
> We know that. Nobody discusses that you can use a full pathname to
> load a DLL from an arbitrary place. Only the convenience of handling
> the installation of DLLs in arbitrary places. (Well, not only; we're
> mainly discussing the convenience of turning Emacs into a distribution
> point for arbitrary Windows binaries from other projects; but I
> digress.)

I don't know how a key component for an Emacs feature can be deemed as
"arbitrary".

As far as I'm concerned, there are two sane options here: suppose that
the user is a geek, advertise GnuTLS support citing the dll requirement
finishing with "now that's your problem". The other approach is to do
the job from Emacs, do it well, and automatically download and upgrade
the dll from Elpa.

Related to this, I'm convinced that Emacs packages too much on the
standard distribution. Things like org-mode, Gnus, Semantic... would be
better on Elpa. That would free resources from the Emacs developers
(less packaging, less maintenance, less administratrivia...), free
resources from the package developers (no merging back and forth) and,
finally, would provide the users updated packages. Oh, and would
diminish the pressure for releasing new Emacs versions.

>> In
>> any case, creating a new function that loads a .dll by name seems quite
>> straightforward, once we have seem how w32_delayed_load is implemented.
>
> What do you mean?

Just that if w32_delayed_load does not fit the bill, writing the
required function by tweaking w32_delayed_load is so easy that someone
like me who doesn't know the Emacs C dialect can do the job.