We don't need two separate byte-compile functions. A slightly updated elisp-compile can be used in almost all cases, and the few (if any) ebuilds could use their own custom code. Use this bug as a tracker for ebuild still calling elisp-comp.
Created attachment 163544 [details, diff] Changes for elisp-common.eclass This is already in the Emacs overlay for testing.
(In reply to comment #0) > [...] the few (if any) ebuilds could use their own custom code. The few *remaining* ebuilds (i.e. that can't use elisp-compile) could use their own custom code.
Packages in category app-emacs that are still using elisp-comp (not filing separate bugs for them): aspectj4emacs cc-mode delicious distel easypg emacs-jabber emacs-wget emacs-wiki fff gnuserv http-emacs icicles matlab mldonkey ocaml-mode python-mode ruby-mode slime sumibi tdtd tnt tuareg-mode view-process yatex
(In reply to comment #3) > Packages in category app-emacs that are still using elisp-comp (not filing > separate bugs for them): > > aspectj4emacs > cc-mode > delicious > distel > easypg > emacs-jabber > emacs-wget > emacs-wiki > fff > gnuserv > http-emacs > icicles > matlab > mldonkey > ocaml-mode > python-mode > ruby-mode > slime > sumibi > tdtd > tnt > tuareg-mode > view-process All done. > yatex This was a false positive. (In reply to comment #2) > The few *remaining* ebuilds (i.e. that can't use elisp-compile) could use > their own custom code. It turns out that there is none, all can use the new elisp-compile.
