[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../s

From: Eli Zaretskii
Subject: bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist.
Date: Mon, 30 Jul 2012 16:30:11 +0300

> From: Jan Djärv <address@hidden>
> Date: Mon, 30 Jul 2012 08:05:04 +0200
> Cc: Glenn Morris <address@hidden>,
>  Stefan Monnier <address@hidden>,
>  Chong Yidong <address@hidden>,
>  address@hidden
> >> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]