bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Jan Djärv
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 08:05:04 +0200

30 jul 2012 kl. 05:34 skrev Eli Zaretskii:

>> From: Glenn Morris <rgm@gnu.org>
>> Cc: 11959@debbugs.gnu.org
>> Date: Sun, 29 Jul 2012 19:50:28 -0400
>> 
>> Eli Zaretskii wrote:
>> 
>>> It would be easy enough to make sure the site-lisp directories exist
>>> before adding them to EMACSLOADPATH on Windows. 
>> 
>> That's probably the simplest solution.
> 
> I will do that, if this is the consensus.  Stefan, Chong, what say
> you?
> 
>> Or make the install create them, as the POSIX installation does.
> 
> The problem happens when you run the uninstalled binary as well.
> 
>> 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.

        Jan D.






reply via email to

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