Re: Trouble with byte-compiling .el files on Emacs update
On Wed, Aug 06, 2008 at 09:07:48AM -0700, Michael Olson wrote:
> Hilko Bengen <firstname.lastname@example.org> writes:
> > Michael Olson <email@example.com> writes:
> >>> When semantic is installed or upgraded -- yes. But what happens when
> >>> $FLAVOR is upgraded?
> >> It ought to call emacs-remove $FLAVOR, followed by emacs-install
> >> $FLAVOR, which would recompile the Emacs Lisp packages in a
> >> dependency-first manner.
> > It ought to, yes, but this dependency-based ordering is not happening.
> > And, franky, I don't think it's worth the effort to re-build apt-like
> > logic on this much smaller scale since just using the source files
> > (.el) accomplishes the same thing and the only thing that would wasted
> > is CPU cycles for parsing Elisp text vs. Elisp bytecode.
> In that case it would make sense to use the uncompiled source.
> Also, I realized that all of the subdirectories in
> /usr/share/$FLAVOR/site-lisp get added to the load-path automatically,
> even when --no-site-flag and -q are passed. This might possibly be due
> to /usr/share/$FLAVOR/site-lisp/subdirs.el.
I think I wrote once to the list about this very same problem, but got no
reply. IIRC xemacs does not use that /usr/share/$FLAVOR/site-lisp/subdirs.el,
and IMHO is not at all needed, since packages are required by policy to
explicitly add its path to the load-path. As a matter of fact nobody seems
to have complained about xemacs not having that subdirs.el.
Unless I am missing something those /usr/share/$FLAVOR/site-lisp/subdirs.el
should either be removed from Debian emacs21 and emacs22 or, if that comes
from upstream and people expects it, a new path with no subdirs.el be used
for Debian packages. I was considering at some time to explicitly break
policy and use something like /usr/share/$FLAVOR/pkg-site-lisp. Since for
Debian nobody is expected to manually add local stuff under
/usr/share/$FLAVOR/site-lisp, removing those
/usr/share/$FLAVOR/site-lisp/subdirs.el is my favourite choice.
> Here is one workaround that would need to be added to path.el. It
> definitely is not an improvement to the aesthetic look of file, but it
> works :^) .
> ; Remove all site-lisp directories from load-path
> (let (new)
> (dolist (path load-path)
> (unless (string-match "/site-lisp" path)
> (setq new (cons path new))))
> (setq load-path (nreverse new)))