bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Glenn Morris <rgm@gnu.org>, cyd@gnu.org, 11959@debbugs.gnu.org
> Date: Wed, 01 Aug 2012 16:32:01 -0400
> 
> >> > I would encourage to rewrite that code on all platforms to allow
> >> > relocation of the binary, since that cannot be bad on any platform.
> >> I think this would be pretty straightforward to implement (bascially
> >> just copy what the NS port does), if considered generally desirable.
> > I'm waiting for Stefan and Chong to chime in.
> 
> Sounds fine to me,

Upon studying the NS code, I didn't like it.  It's too
platform-specific (so would require implementing the same stuff at
least one more time), and it bypasses most of the code in emacs.c,
callproc.c, and lread.c that sets up the various VFOO_directory and
VBAR_path variables on Posix platforms, and IMO for no good reason,
since the logic of that code is generally correct and useful.

So instead I made a few changes in decode_env_path that allow use of a
"magical" prefix in strings defined in epaths.h.  That prefix is
expanded at startup time into the root of the Emacs tree, either
installation tree or the source tree.  (Some changes to support these
were needed in w32.c and nt/paths.h, as well.)  This allows to leave
the logic in init_lread and other similar places intact, and still
DTRT both in installed and uninstalled Emacs.  The advantage of this
is that making this work on all the other platforms is (I hope)
_really_ trivial; we just need to agree on some suitable replacement
for the %emacs_dir% thingy.

The changes I installed (in trunk revision 109429) are for MS-Windows
only for now.

This eliminates the annoying warning that started this bug report, and
I'm therefore marking this bug as done.