--- Begin Message ---
Subject: |
"make install" has trouble with non-standard locallisppath directories |
Date: |
Sat, 8 Jun 2013 16:15:33 +0200 |
Package: emacs
Version: 24.3.50
On Windows, using the MSYS build machinery.
If you need to add a non-default lisp directory to the path, by
following nt/INSTALL.MSYS recommendation of doing, for example
./nt/msysconfig.sh
--enable-locallisppath='%emacs_dir%/../site-lisp;%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp'
then "make install" will try to create these directories *in the build
tree* (not the installation dir), and do a poor job at it. In the
above case, after make install the build tree will contain these
directories:
%emacs_dir%
site-lisp;%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp
"%emacs_dir%" is literal, an unexpanded environment variable.
Makefile.in contains this old note:
## I'm not sure creating locallisppath here serves any useful purpose.
## If it has the default value, then the later write_subdir commands
## will ensure all these components exist.
## This will only do something if locallisppath has a non-standard value.
## Is it really Emacs's job to create those directories?
## Should we also be ensuring they contain subdirs.el files?
## It would be easy to do, just use write_subdir.
and indeed, I would argue that is not Emacs' job to create them. If
the user is knowledgeable enough to have to use
--enable-locallisppath, s/he'll also know enough to make sure the
directories exist and contain subdirs.el as required.
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#14576: "make install" has trouble with non-standard locallisppath directories |
Date: |
Thu, 27 Jun 2013 04:02:28 +0200 |
On Sat, Jun 8, 2013 at 5:05 PM, Eli Zaretskii <address@hidden> wrote:
> I removed from nt/INSTALL.MSYS the example that made it sound as if
> %emacs_dir% is supported.
Now that locallisppath does not create directories, I'd suggest
reverting revno:112894 and re-adding the comment about using
%emacs_dir%. It is useful advice.
In fact, I'd go so far as to suggest adding a note about @VER@ (yes,
full of caveats and warnings and whatnot about it being unsupported
and an implementation detail, but still...)
J
--- End Message ---