Re: Recompiling elisp files (Re: Taking over production of emacs20 package.)
>>>>> "Manoj" == Manoj Srivastava <srivasta@datasync.com> writes:
Manoj> Hi,
>>> "Christian" == Christian Lynbech <lynbech@daimi.aau.dk> writes:
Christian> I am not quite so pessimistic about the possibilities of
Christian> recompiling installed elisp files.
Manoj> Please, people, do download the sources for tm and compile a
Manoj> local copy before you display such unwarranted optimism
Manoj> ;-).
I know both hyperbole and tm, since I maintain both at the local emacs
installation. Communicatin with the tm build process is close to being
the most complicated thing I have encountered as an emacs hacker :-)
Manoj> I am including the Makefile in the tm/ subdirectory
Manoj> below. Running make in that directory triggers recusive makes
Manoj> in all sibling directories, and the make run is modified by
Manoj> elisp in several *-CONFIG files.
Sure thing, but once the files are installed, it should be possible
(save for ordering) to recompile the stuff file-by-file without going
through the large procedure of the real build process.
Manoj> Umm, hyperbole and tm both have multidirectory complex make
Manoj> relationships; and unless we ship the make files in the
Manoj> distribution (/usr/lib/emacs/site-lisp/tm/Makefile?), it is
Manoj> difficult indeed to compile them in a postinst hook (it can be
Manoj> done, at the expense of potentially having to re-craft the
Manoj> compiler on upstream upgrades).
Well, I'm still optimistic. Working recursively through directories is
not difficult (byte-recompile-directory already does this), so if I am
correct that we "only" need to compile in the right order (and that we
can do that), it is doable.
Manoj> Debian does not use the concatenated elc files option; we do
Manoj> use the little files.
I used it mainly as an example, since this is the one package that I
know of that will produce an .elc file which does not correspond to an
.el file.
Manoj> But the little files are not generated in random order;
No, but I claim we can fix this, in the sense that we either can
record the order and supply it to the process (simpler than having to
supply a fullblown makefile; for instance tm uses files that are not
part of the installed set) or deduce it automatically. It should be
straightforward (allthough not trivial) to walk a set of elisp files,
recording which files defines what functions and where these functions
are used, and then do a topological sort to detemine the compilation
order.
Manoj> Quassia Gnus, vm, tm, bbdb, w3, hyperbole, .... (need I go
Manoj> further?). The problem maybe masked for red gnus if an older
Manoj> version of the el/elc files is installed in the standard path;
Manoj> I do not think that bbdb and hyperbole compile with older
Manoj> versions.
I do not think things are that bad. I did a quick test on our
w3-2.2.26 installation (doing `emacs -batch -q -f batch-byte-compile *.el')
and the only error I got was from w3-xemac.el, since I have not
installed w3-toolbar. And as said, one can do the alphabetical
recompile on the standard lisp/ directory without problems.
Ok, enough hot air. I'll go back and do some more thinking and
testing. I will have a look at the compilation order analyzer and try
to check some of the packages for these ordering problems.
---------------------------+--------------------------------------------------
Christian Lynbech | Computer Science Department, University of Aarhus
Office: R0.32 | Ny Munkegade, Building 540, DK-8000 Aarhus C
Phone: +45 8942 3218 | lynbech@daimi.aau.dk -- www.daimi.aau.dk/~lynbech
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- petonic@hal.com (Michael A. Petonic)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: