Re: Emacs addon packages--compile upon install?
***** RB => Rob Browning
RB> The main reasons I recall were that we didn't want to have 4 (or
RB> more later) different copies of each package on all the ftp sites,
RB> and we didn't want to have to have every add-on package maintainer
RB> install *every* flavor of emacs. We also didn't want to have to
RB> have add-on package maintainers worry about whether or not they
RB> needed to build a new release every time any emacs package was
RB> upgraded. Since the packages re-compile themselves on upgrade or
RB> install, they are less sensitive to emacsen main pacakge changes.
As one of the Emacs add-on package maintainers (Eapm) I strongly
object to switch back to the model that w3 apparently implements now
(aka the old model), for the very reasons you restated above.
Moreover I really like our new approach, as I think is simpler,
elegant, fault tolerant (just think about how many different emacsen
are there out there: not every site may be using one of those we ship
with Debian, and our precompiled `binary' may fail to work with
some of them).
In my opinion we did The Right Thing or, at least, a big step forward
with the new emacsen scheme. The only (known) drawback is
installation time, but this is probably a minor issue, since you won't
install every day and since this time tends to get reduced by
the ever increasing computing power of modern machines.
By the way, as a side note, I'd like to suggest other Eapms to _not_
display the results of byte-compilation on the console at installation
time, redirecting them to some file instead: it's really annoying to
see a very long list of probably useless warnings about free variables
or functions not known to be defined. However those results are
useful things to have around on every machine (e.g. to ask the user to
check them in case a bug is being investigated), so why don't put them
somewhere they could be easily retrieved if needed?
My packages currently store them in:
/usr/share/emacs/<version>/site-lisp/<package>/CompilationLog.gz
Maybe we can find a standard name and place.
Thanks,
--
Davide G. M. Salvetti - IW5DZC [JN53fr] - <http://salve.home.ml.org/>
Reply to: