From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Wed, 04 Jan 2012 03:15:57 -0500 Message-ID: References: <87k45alwgb.fsf@wanadoo.es> <87fwfyltm1.fsf@wanadoo.es> <87boqmlrma.fsf@wanadoo.es> <87ty4e9j19.fsf@lifelogs.com> <83obumqa0v.fsf@gnu.org> <87ipktag2e.fsf@lifelogs.com> <87fwfxtxuz.fsf@wanadoo.es> <87aa64ubg9.fsf@wanadoo.es> <83boqkr9bp.fsf@gnu.org> <874nwcu17i.fsf@wanadoo.es> <834nwcr6un.fsf@gnu.org> <87vcosskhc.fsf@wanadoo.es> <831urgr2yr.fsf@gnu.org> <87r4zgsh2w.fsf@wanadoo.es> <83y5topmyv.fsf@gnu.org> <87r4zgynd5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1325664968 2974 80.91.229.12 (4 Jan 2012 08:16:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 08:16:08 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 04 09:16:04 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RiM0x-0005Rz-No for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 09:16:03 +0100 Original-Received: from localhost ([::1]:47979 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiM0w-0003eB-OB for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 03:16:02 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiM0u-0003ds-9V for emacs-devel@gnu.org; Wed, 04 Jan 2012 03:16:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiM0t-0003Ea-3I for emacs-devel@gnu.org; Wed, 04 Jan 2012 03:16:00 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:39233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiM0t-0003EW-1k for emacs-devel@gnu.org; Wed, 04 Jan 2012 03:15:59 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RiM0r-0005kz-QF; Wed, 04 Jan 2012 03:15:57 -0500 In-reply-to: <87r4zgynd5.fsf@gnu.org> (message from Chong Yidong on Wed, 04 Jan 2012 14:48:22 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147256 Archived-At: > From: Chong Yidong > Cc: Óscar Fuentes , emacs-devel@gnu.org > Date: Wed, 04 Jan 2012 14:48:22 +0800 > > Eli Zaretskii writes: > > >> From: Óscar Fuentes > >> Date: Tue, 03 Jan 2012 20:48:23 +0100 > >> > >> 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) ? > > > > Because load-path is used for loading Lisp, but not for loading DLLs. > > The code in a Lisp package can extract its package directory from the > variable `load-file-name'. The Multi-file Packages node of the Lisp > manual gives an example of this. The issue is not figuring out the directory where the DLL lives. The issue is instructing the code that needs to load that DLL where to look for it. Currently, we load the DLLs by specifying their basename, without leading directories, which causes the corresponding Windows API to search for the DLL in known places, as documented in the MS documentation. To change that and give Lisp programs control of where to look for DLLs, we need changes on the C level. The other problem is how to upgrade a DLL from an Emacs session that already uses the previous version of that DLL. I think this is hard without restarting Emacs, and not trivial even with restarting. > I'm not saying we should distribute GnuTLS support via ELPA, only that > the Package system is no technical barrier. The barrier I was talking about has nothing to do with package.el.