GNU bug report logs - #14513
24.3.50; Site load-path pieces differ in MSYS build

Previous Next

Package: emacs;

Reported by: Richard Copley <rcopley <at> gmail.com>

Date: Thu, 30 May 2013 13:49:02 UTC

Severity: wishlist

Merged with 14514

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #29 received at 14513 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14513 <at> debbugs.gnu.org
Subject: Re: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build
Date: Thu, 30 May 2013 20:20:18 +0100
[Message part 1 (text/plain, inline)]
On 30 May 2013 19:20, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 30 May 2013 18:56:10 +0100
> > From: Richard Copley <rcopley <at> gmail.com>
> > Cc: 14513 <at> 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?
[Message part 2 (text/html, inline)]

This bug report was last modified 12 years and 45 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.