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 00:21:20 -0500 Message-ID: References: <83wr9bqez3.fsf@gnu.org> <87y5tr9dwv.fsf_-_@lifelogs.com> <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> <87ipks3zbo.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1325654490 11671 80.91.229.12 (4 Jan 2012 05:21:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 05:21:30 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 04 06:21:26 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 1RiJHx-0000K7-Gg for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 06:21:25 +0100 Original-Received: from localhost ([::1]:53133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiJHw-0008OS-KM for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 00:21:24 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiJHt-0008Mf-Ps for emacs-devel@gnu.org; Wed, 04 Jan 2012 00:21:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiJHs-0005b7-Ll for emacs-devel@gnu.org; Wed, 04 Jan 2012 00:21:21 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:37360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiJHs-0005b3-HB for emacs-devel@gnu.org; Wed, 04 Jan 2012 00:21:20 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RiJHs-0006pO-33; Wed, 04 Jan 2012 00:21:20 -0500 In-reply-to: <87ipks3zbo.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) 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:147251 Archived-At: > From: "Stephen J. Turnbull" > 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.