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#14513: 24.3.50; Site load-path pieces differ in MSYS build Date: Thu, 30 May 2013 21:20:59 +0300 Message-ID: <83r4go49dg.fsf@gnu.org> References: <83y5aw4e0x.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1369938111 32052 80.91.229.3 (30 May 2013 18:21:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 May 2013 18:21:51 +0000 (UTC) Cc: 14513@debbugs.gnu.org To: Richard Copley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 30 20:21:50 2013 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 1Ui7Tv-0005c0-7R for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 May 2013 20:21:47 +0200 Original-Received: from localhost ([::1]:55209 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui7Tu-0005lw-P1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 May 2013 14:21:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui7Tn-0005kn-Uz for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 14:21:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui7Tg-000242-FJ for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 14:21:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui7Tg-00023x-CD for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 14:21:32 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Ui7V8-0002TC-IX for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 14:23: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: Thu, 30 May 2013 18:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14513 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14513-submit@debbugs.gnu.org id=B14513.13699381589441 (code B ref 14513); Thu, 30 May 2013 18:23:02 +0000 Original-Received: (at 14513) by debbugs.gnu.org; 30 May 2013 18:22:38 +0000 Original-Received: from localhost ([127.0.0.1]:42728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ui7Uj-0002SD-Tb for submit@debbugs.gnu.org; Thu, 30 May 2013 14:22:38 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:39755) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ui7Uh-0002Rs-6e for 14513@debbugs.gnu.org; Thu, 30 May 2013 14:22:36 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MNM00A00IY3IR00@a-mtaout22.012.net.il> for 14513@debbugs.gnu.org; Thu, 30 May 2013 21:20:42 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MNM0099TIYIIAD0@a-mtaout22.012.net.il>; Thu, 30 May 2013 21:20:42 +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.x 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:74668 Archived-At: > Date: Thu, 30 May 2013 18:56:10 +0100 > From: Richard Copley > Cc: 14513@debbugs.gnu.org > > What used sometimes to be called NT Emacs is (or was) a portable app. > When you've unpacked (or built) it, everything is inside "bin/..". > Call that the "application directory". You install by moving and > renaming the application directory, and uninstall by deleting. > Ideally, you never modify any file inside the application directory. > Putting an Emacs bin directory on the system-wide path is optional. > The user can be trusted to work out how to invoke the right executable. > Emacs finds the right auxiliary executables and DOC file just fine, > even with the "-Q" command-line argument. This is all still true, except that some of the directories are not immediately below the root of the installation tree, but somewhat deeper. E.g., what was previously in ROOT/lisp is now in ROOT/share/emacs/VERSION/lisp. Why is that difference important? > I had a bunch of these application directories, my own builds of the > trunk, at different revisions. Like this (but with more Emacs): > > c:\>dir /B c:\emacs > emacs-111818 > emacs-112125 > emacs-112416 > site-lisp You can still have separate directories like that, unless I'm missing something. The directory structure below emacs-NNNNNN directories will be different, but that's all. > This particular arrangement was suggested, to my mind anyway, by > the existence of the "%emacs_dir%/../site-lisp" entry in load-path. Did you really have files in "%emacs_dir%/../site-lisp"? If you did, you'd probably be the first one I know about who did. Most people don't even know that directory is looked in. If you do have files in this directory, you'll have to copy them into each new tree, if you really want the threes to be separate, not under a single root. But you'll probably need that anyway, because Lisp files had better be compiled by the Emacs version that runs them. > I don't say it's impossible to do the same thing any more, just that > it no longer works out of the box as it used to What exactly doesn't work? Uninstalling by removing a single tree? Or something else? If that's uninstalling, and you don't want or cannot "make uninstall", it should be easy to create a simple script that, given a root directory and a version, will delete the subdirectories that belong to that version only. There aren't too many directories to delete, basically libexec/emacs/VERSION and share/emacs/VERSION. That, and the emacs-VERSION*.exe executables in bin/. Did I miss something? > If, as you say, it's a design decision, then that's fine. I disagree > but I don't object. The new structure has advantages which I described in that mail in March.