On 30 May 2013 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@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?