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

Previous Next

Full log

View this message in rfc822 format

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14513 <at> debbugs.gnu.org
Subject: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build
Date: Thu, 30 May 2013 18:56:10 +0100

[Message part 1 (text/plain, inline)]

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

> > Date: Thu, 30 May 2013 14:46:13 +0100
> > From: Richard Copley <rcopley <at> gmail.com>
> >
> > The site-specific pieces of the initial load-path are different in the
> > nt/msysconfig.sh build from how they used to be with nt/configure.bat.
>
> Indeed, and that is on purpose.  I explained the rationale here:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00146.html
>
> > In src/epaths.h (when built), PATH_SITELOADSEARCH is defined as:
> >
> >   with nt/configure.bat: "%emacs_dir%/site-lisp;%emacs_dir%/../site-lisp"
> >
> >   with nt/msysconfig.sh:
> >
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> >
> > The former version was much more useful on Windows, allowing
> > one to keep a bunch of Emacs installs in a single parent directory
> > that also contains the site-lisp directory.
>
> Sorry, I don't follow.  Please describe what structure was possible
> beforehand that you think is impossible now.
>

I'm not sure which part you're having trouble with, so I'll be quite
expansive and hopefully you'll see what I mean. Perhaps this should be
a reply to the emacs-devel message, but I didn't see that at the time
and it's a bit late now.

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.

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

This particular arrangement was suggested, to my mind anyway, by
the existence of the "%emacs_dir%/../site-lisp" entry in load-path.

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 (unless of course I've
made some other mistake). If, as you say, it's a design decision, then
that's fine. I disagree but I don't object.

[Message part 2 (text/html, inline)]

Previous Next

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