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

Re: Trouble with byte-compiling .el files on Emacs update



Sven Joachim <svenjoac@gmx.de> writes:

> On 2008-07-26 23:00 +0200, Hilko Bengen wrote:
>> Source file `/usr/share/emacs22/site-lisp/sepia/snippet.el' newer than byte-compiled file
>
> Not related to your problem, but this looks strange. Why does the
> byte-compiled file exist and why is the source newer?

No idea. This hasn't happened since.

> Probably emacs-install would need to be changed to take package
> dependencies into account, but the emacsen-common package does not
> seem to be maintained currently.

I'm not sure whether it's such a good idea to add dependency handling
to emacs-install.

> I think you can work around this by specifying the path to w3m-perldoc
> in the require call, like this:
>
> (eval-when-compile
>   (require 'w3m-perldoc "w3m/w3m-perldoc"))
>
> This will load the file from /usr/share/emacs/site-lisp, if no
> byte-compiled file from /usr/share/emacs22/site-lisp exists yet.

No such luck:

[...]
In toplevel form:
sepia-w3m.el:37:13:Error: Cannot open load file: w3m
Wrote /usr/share/emacs22/site-lisp/sepia/snippet.elc
emacs-install: /usr/lib/emacsen-common/packages/install/sepia emacs22 failed at /usr/lib/emacsen-common/emacs-install line 28, <TSORT> line 56.
dpkg: error processing emacs22-gtk (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 emacs22-gtk
E: Sub-process /usr/bin/dpkg returned an error code (1)


It turns out that w3m-perldoc requires w3m which isn't really
surprising. :-)

My workaround consists of adding the source directory for w3m-el to
the load-path when sepia is byte-compiled.

Cheers,
-Hilko


Reply to: