From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist. Date: Mon, 30 Jul 2012 06:34:37 +0300 Message-ID: <836295hqgi.fsf@gnu.org> References: <623F1AC1C2E540D09676869BBDA4B15A@us.oracle.com> <83hat69thh.fsf@gnu.org> <838veh9kxu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1343619302 11846 80.91.229.3 (30 Jul 2012 03:35:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 30 Jul 2012 03:35:02 +0000 (UTC) Cc: 11959@debbugs.gnu.org To: Glenn Morris , Stefan Monnier , Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 30 05:35:01 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Svgkz-0004DA-IG for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jul 2012 05:34:57 +0200 Original-Received: from localhost ([::1]:39172 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svgky-0001ft-QC for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 23:34:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svgkv-0001br-3K for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 23:34:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svgkt-0003rL-S3 for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 23:34:53 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40176) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svgkt-0003rF-OC for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 23:34:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Svgrq-0001kt-Ee for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 23:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jul 2012 03:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11959 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11959-submit@debbugs.gnu.org id=B11959.13436197006706 (code B ref 11959); Mon, 30 Jul 2012 03:42:02 +0000 Original-Received: (at 11959) by debbugs.gnu.org; 30 Jul 2012 03:41:40 +0000 Original-Received: from localhost ([127.0.0.1]:49722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvgrT-0001k5-Fj for submit@debbugs.gnu.org; Sun, 29 Jul 2012 23:41:39 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:40504) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvgrR-0001jv-Lz for 11959@debbugs.gnu.org; Sun, 29 Jul 2012 23:41:38 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M7Y00H00F1OE100@a-mtaout20.012.net.il> for 11959@debbugs.gnu.org; Mon, 30 Jul 2012 06:34:25 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7Y00HI0F9C4270@a-mtaout20.012.net.il>; Mon, 30 Jul 2012 06:34:25 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:62602 Archived-At: > From: Glenn Morris > Cc: 11959@debbugs.gnu.org > Date: Sun, 29 Jul 2012 19:50:28 -0400 > > Eli Zaretskii wrote: > > > It would be easy enough to make sure the site-lisp directories exist > > before adding them to EMACSLOADPATH on Windows. > > That's probably the simplest solution. I will do that, if this is the consensus. Stefan, Chong, what say you? > Or make the install create them, as the POSIX installation does. The problem happens when you run the uninstalled binary as well. > Actually, my recommendation would be to stop setting EMACSLOADPATH (and > the other EMACS* environment variables...) on MS Windows, similar to > what I recently did for the NS port. I don't see how this is possible. Emacs on Windows is built to be relocatable, because many users install precompiled binaries in any place they feel like. So Emacs on Windows must determine its load-path at run time. By contrast, the mainline code relies on file names hardwired into the executable at configure/build time, which is a non-starter. What other devices do we have for forcing load-path to have a specific value, except setting EMACSLOADPATH? I could, of course, ifdef away the entire code that does that on lread.c, and put there a Windows specific code instead, but is that really a better alternative? I would encourage to rewrite that code on all platforms to allow relocation of the binary, since that cannot be bad on any platform. But until that happens, do you see a better way than set EMACSLOADPATH? > > And if we do want to check that, why not exempt the site-lisp > > directories from the need to exist, like we do in the case where > > EMACSLOADPATH is not set? > > Because I assumed people setting EMACSLOADPATH would only include > existing directories, and would want to be warned about missing ones. > I overlooked that MS Windows adds site-lisp directories without checking > they exist. Also there's no clean way to detect what a site-lisp > directory is in the EMACSLOADPATH case (simply checking for site-lisp in > the name is not robust). Checking for site-lisp is better than nothing, though.