From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build Date: Thu, 30 May 2013 20:20:18 +0100 Message-ID: References: <83y5aw4e0x.fsf@gnu.org> <83r4go49dg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c38f0c8609eb04ddf46349 X-Trace: ger.gmane.org 1369941790 8736 80.91.229.3 (30 May 2013 19:23:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 May 2013 19:23:10 +0000 (UTC) Cc: 14513@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 30 21:23:09 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 1Ui8RI-0002qA-Uu for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 May 2013 21:23:09 +0200 Original-Received: from localhost ([::1]:59863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui8RI-0008CG-Gs for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 May 2013 15:23:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui8RA-0008C1-7J for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 15:23:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui8Ol-0006hp-UJ for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 15:20:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui8Ol-0006hY-NS for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 15:20:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Ui8QE-0004kP-F4 for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 15:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 May 2013 19:22: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.136994171918236 (code B ref 14513); Thu, 30 May 2013 19:22:02 +0000 Original-Received: (at 14513) by debbugs.gnu.org; 30 May 2013 19:21:59 +0000 Original-Received: from localhost ([127.0.0.1]:42839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ui8QA-0004k4-H8 for submit@debbugs.gnu.org; Thu, 30 May 2013 15:21:59 -0400 Original-Received: from mail-ea0-f182.google.com ([209.85.215.182]:42064) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ui8Q7-0004ji-7o for 14513@debbugs.gnu.org; Thu, 30 May 2013 15:21:56 -0400 Original-Received: by mail-ea0-f182.google.com with SMTP id r16so746894ead.41 for <14513@debbugs.gnu.org>; Thu, 30 May 2013 12:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e27IbAd2rFDQlzi0X4p7A17zC/AdI4IJNsJzDJobEz8=; b=L13v/X3BTU7raUFGXE8sqnxZ5ipvMEgfvPEunEqi2k/RC6f9n9RJ4surjWHJj6E2ln 3TkR1gm4p7v2dAkaYBx8zaCYbjpQRsIxkpvJgVEb1q6DE3UrldbeH6p+te3ib0GnqPE+ zNIL5rkje87Qo24y2oJrnFJ4qwbi65bHIMrDW1JYoHZeruh1xmTdKSW2Hi5KMOozReg4 axSeSJ/Jx2pMc7UB5huHgfRuDZp/jlf7gbSewfJ7ThmbTHT1YeE/XLdrdEVK3pf7pBt3 j83RQrxm7+3qsVTixMMXbdE174KMG0/wnnYVRzBW51pwA7OdkECqSxFy0nJyul6z32wU 09YA== X-Received: by 10.14.100.68 with SMTP id y44mr10678230eef.70.1369941618317; Thu, 30 May 2013 12:20:18 -0700 (PDT) Original-Received: by 10.14.212.67 with HTTP; Thu, 30 May 2013 12:20:18 -0700 (PDT) In-Reply-To: <83r4go49dg.fsf@gnu.org> 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:74675 Archived-At: --001a11c38f0c8609eb04ddf46349 Content-Type: text/plain; charset=ISO-8859-1 On 30 May 2013 19:20, Eli Zaretskii wrote: > > 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, Oh no it isn't. 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? > That difference is not 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. > Also the site-lisp directory will not be on the load-path. > > 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"? Yes, that site-lisp directory up there is where my site lisp files are, really. > 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 say so. I'm the freak who looked at load-path. :P 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. That seems like a disadvantage. > But you'll probably need that anyway, because Lisp > files had better be compiled by the Emacs version that runs them. > That's a fair point. I've never had a problem but it would be easy enough to recompile as necessary. I'm not actively using more than one build. > 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? > The site-lisp directory is not searched. > If that's uninstalling, and you don't want or cannot "make uninstall". It's funny how differently we work! I can't make uninstall because I kept the installation directory and discarded the build directory. > 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? > With the uninstallation? No idea. It's ok, there's no way I'll be doing that. > > 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. > (1) You're the first one I know about who thinks that's important. (2) is wrong. (3) I don't follow. Other platforms, really? --001a11c38f0c8609eb04ddf46349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 30 May 201= 3 19:20, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Thu, 30 May 2013 18:56:10 +0100
> From: Richard Copley <rcopley@gmail.com>
> Cc: 14513@d= ebbugs.gnu.org
>
> What used sometimes to be called NT Emacs is (or was) a portable app.<= br> > 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,

Oh no i= t isn't.

except that some of the directories are not
immediately below the root of the installation tree, but somewhat
deeper. =A0E.g., what was previously in ROOT/lisp is now in
ROOT/share/emacs/VERSION/lisp. =A0Why is that difference important?

That difference is not important.
<= div class=3D"im">
> I had a bunch of these application directories, my own builds of the > trunk, at different revisions. Like this (but with more Emacs):
>
> =A0 c:\>dir /B c:\emacs
> =A0 emacs-111818
> =A0 emacs-112125
> =A0 emacs-112416
> =A0 site-lisp

You can still have separate directories like that, unless I'm mis= sing
something. =A0The directory structure below emacs-NNNNNN directories
will be different, but that's all.

Also the site-lisp directory will not be on the load-path.
<= div class=3D"im">
=A0
> This particular arrangement was suggested, to my mind anyway, by
> the existence of the "%emacs_dir%/../site-lisp" entry in loa= d-path.

Did you really have files in "%emacs_dir%/../site-lisp"?

Yes, that site-lisp directory up there = is where my site lisp files are, really.
=A0
If you did,
you'd probably be the first one I know about who did. =A0Most people don't even know that directory is looked in.

<= /div>
If you say so. I'm the freak who looked at load-path. := P

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.

That seems like a disa= dvantage.
=A0
=A0But you'll probably need that anyway, because Lisp
files had better be compiled by the Emacs version that runs them.

That's a fair point. I've never ha= d a problem but it would be easy enough
to recompile as necessary. I'= ;m not actively using more than one build.

> I don't say it's impossible to do the same thing any more, jus= t that
> it no longer works out of the box as it used to

What exactly doesn't work? =A0Uninstalling by removing a single t= ree?
Or something else?

The site-lisp = directory is not searched.
=A0
If that's uninstalling, and you don't want or cannot "make uni= nstall".

It's funny how differently we work! = I can't make uninstall because
I kept the installation directory and= discarded the build directory.
=A0
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. =A0There aren't too many directories to delete,
basically libexec/emacs/VERSION and share/emacs/VERSION. =A0That, and
the emacs-VERSION*.exe executables in bin/.

Did I miss something?

With the un= installation? No idea. It's ok, there's no way I'll be doing th= at.
=A0
> If, as you say, it's a design decision, then that's fine. I di= sagree
> but I don't object.

The new structure has advantages which I described in that mail in March.

(1) You're the first one I know about who = thinks that's important.
(2) is wrong.
(3) I don't follow. Ot= her platforms, really?
--001a11c38f0c8609eb04ddf46349--