bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii <eliz@gnu.org>]

> 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, 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?

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

> 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"?  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 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.  But you'll probably need that anyway, because Lisp
files had better be compiled by the Emacs version that runs them.

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

If that's uninstalling, and you don't want or cannot "make uninstall",
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?

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