--- Begin Message ---
|
Subject: |
24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist. |
|
Date: |
Tue, 17 Jul 2012 09:40:31 -0700 |
I do not see this warning message with emacs -Q, but I see it with my
setup. I do not find anywhere in my setup where I refer to site-lisp,
but perhaps I do somewhere.
When I start Emacs this warning is the first thing in buffer *Messages*:
Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist.
My directory structure is this:
C:/Emacs-24-2012-07-16 contains the following, all of which comes
from the Windows binary I downloaded from GNU:
bin/
etc/
info/
leim/
lisp/
site-lisp/
.gdbinit
BUGS
COPYING
README
README.W32
I made no changes to the directory content or structure, apart from
renaming the top-level directory to Emacs-24-2012-07-16.
So why the warning? Why is Emacs looking for a site-lisp directory above
directory Emacs-24-2012-07-16? And what does this all mean?
In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
of 2012-07-16 on MARVIN
Bzr revision: 109106 address@hidden
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --no-opt --enable-checking --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include
-ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
-ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist. |
|
Date: |
Sat, 04 Aug 2012 17:30:12 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: Glenn Morris <address@hidden>, address@hidden, address@hidden
> 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.
--- End Message ---