On 30 May 2013 19:20, Eli Zaretskii <address@hidden>
> Date: Thu, 30 May 2013 18:56:10 +0100
> From: Richard Copley <address@hidden>
> Cc: address@hidden
>This is all still true,
> 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.
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 theYou can still have separate directories like that, unless I'm missing
> trunk, at different revisions. Like this (but with more Emacs):
> c:\>dir /B c:\emacs
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, byDid you really have files in "%emacs_dir%/../site-lisp"?
> the existence of the "%emacs_dir%/../site-lisp" entry in load-path.
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 thatWhat exactly doesn't work? Uninstalling by removing a single tree?
> it no longer works out of the box as it used to
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 disagreeThe new structure has advantages which I described in that mail in
> but I don't object.
(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?