[Top][All Lists]

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

Re: package.el: bytecode portability across emacs versions

From: David Kastrup
Subject: Re: package.el: bytecode portability across emacs versions
Date: Mon, 21 May 2007 20:10:47 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

"Trent Buck" <address@hidden> writes:

> Arbitrary emacs lisp cannot be byte-compiled in one version of Emacs
> and loaded in another, as the following transcript shows:


> This is most obvious in the wild in emacs-w3m, but I've had problems
> with other packages also.
> package.el appears to create bytecode in a common directory.

It creates the bytecode in the directory where the source Elisp files
lie, I would presume.

> Unless code is carefully audited, any time .emacs.d is shared
> between multiple emacsen packages errors can be expected.

Sharing such a directory is a mistake, anyway.

> Recommendation: either 0) tell users not to run more than one emacs;
> 1) don't byte-compile; or 2) place bytecode in path(s) local to the
> current emacs-version.
> Debian's elisp package framework adopts (2), that might be a source of
> inspiration.

Debian's Elisp package framework socks boulders through straws.  Emacs
is designed to have Elisp and elc files in the same directory.  That's
how load-path orders can take effect.  Debian completely breaks this,
as witnessed by calling M-x list-load-path-shadows RET.  And, of
course, things like M-x byte-recompile-directory RET don't work in
Debian, either.

Sharing Elisp files between different Emacs variants is not a good

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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