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 #35 received at 14513 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: 14513 <at> debbugs.gnu.org
Subject: Fwd: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build
Date: Thu, 30 May 2013 20:49:40 +0100
[Message part 1 (text/plain, inline)]
Damn damn damn. I meant to forward this message to this bug, but
instead I sent it to bug-gnu-emacs <at> gnu.org. Sorry.

Eli, I didn't mean to reply by private email, and I re-sent my reply
to the list shortly afterwards, as you will have seen by now. I hope
you don't mind me forwarding your reply, which is below, with my
comments inline.

Sorry again for causing extra confusion. I've done similar things on
this list several times before. It's entirely unintentional.  The
Google mail interface makes it very easy to hit reply and slightly
annoying to hit reply-all.

---------- Forwarded message ----------
From: Richard Copley <rcopley <at> gmail.com>
Date: 30 May 2013 20:29
Subject: Fwd: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>


On 30 May 2013 20:28, Eli Zaretskii <eliz <at> gnu.org> wrote:

> [Why private email?]
>
> Date: Thu, 30 May 2013 20:14:35 +0100
> > From: Richard Copley <rcopley <at> gmail.com>
> >
> > > >   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.
>
> Your site-lisp won't, but the one in ROOT/share/emacs will.
>

Yes.


>
> > I'm not actively using more than one build.
>
> Then why do you need separate trees?  That's the only reason why you
> need the site-lisp outside of the Emacs tree.


I don't need separate trees. I find separate trees convenient.


> Use the Posix-standard
> structure and one root for all the Emacs installations, and the
> problem is gone, because you have the common site-lisp directory in
> ROOT/share/emacs.
>

That has its own disadvantages. Are we going round in circles?

> > 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.

You mean, you will never uninstall?  Then why do you keep the versions
> separate?
>

No that's not what I mean.

> > 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.
>
> Well, maybe I'm the only one who works on so many platforms.
>
> (2) is wrong.
>
> It's not wrong as long as you keep all the installations under the
> same root, like /usr/local on Unix.
>

That's true.

> (3) I don't follow. Other platforms, really?
>
> Yes.  Imagine that your --prefix is on a networked volume that can be
> accessed from Windows and Unix systems alike.  Then only the
> architecture-dependent files (binaries) need to be separate;
> everything under %emacs_dir%/share/emacs/ can be installed only once
> and used by Emacs from any OS.
>

No, you've lost me ... Do you actually do that? Where do the binaries go?
[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.