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

[Eli Zaretskii <eliz@gnu.org>]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Mon, 30 Jul 2012 08:05:04 +0200
> Cc: Glenn Morris <rgm@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Chong Yidong <cyd@gnu.org>,
>  11959@debbugs.gnu.org
> 
> 
> >> Actually, my recommendation would be to stop setting EMACSLOADPATH (and
> >> the other EMACS* environment variables...) on MS Windows, similar to
> >> what I recently did for the NS port.
> > 
> > I don't see how this is possible.  Emacs on Windows is built to be
> > relocatable, because many users install precompiled binaries in any
> > place they feel like.  So Emacs on Windows must determine its
> > load-path at run time.  By contrast, the mainline code relies on file
> > names hardwired into the executable at configure/build time, which is
> > a non-starter.  What other devices do we have for forcing load-path to
> > have a specific value, except setting EMACSLOADPATH?  I could, of
> > course, ifdef away the entire code that does that on lread.c, and put
> > there a Windows specific code instead, but is that really a better
> > alternative?
> 
> The NS-port is also fully relocatable and determines load-path at runtime.

Yeah, with "#ifdef HAVE_NS" around it.  That's what I meant by
"Windows specific code" above.