[gentoo-dev] (emacs) proposed site-lisp and byte-compilation improvements

[gentoo-dev] (emacs) proposed site-lisp and byte-compilation improvements

[Matthew Kennedy]

Hi,

I'd like to get a discussion going about possible improvements to
GNU Emacs on Gentoo.  If you got CCed make sure to reply to the
list.  Here are some ideas I've had.

* Firstly, please review this: 

   http://dev.gentoo.org/~mkennedy/emacs/site-gentoo.el-rfc.txt

I would like to see us move to something like the above for
customization.

In no particular order, here are some other changes I propose:

* Move away from the big concatenation of
  /usr/share/emacs/site-lisp/*-gentoo.el into
  /usr/share/site-lisp/site-start.el.

Instead, leave site-start.el alone, and create a site-gentoo.el which
loads each *-gentoo.el file (call these "site hooks") pragmatically.
This has the benefit of freeing up site-start.el for user usage.  The
programmatic approach also allows for the possibility of the user
defining their own site hooks.

* Byte-Compile site-gentoo.el and all site hooks

Perhaps this will make for more rapid load times.

* Install elisp source in such a way that global recompilation is
  possible.

It is a "dirty little secret" that our .elc files from add-on elisp
packages are able to persist between emacs major and minor version
upgrades.  The format of byte-compilation can change between releases,
and allowing these old .elc files to be loaded into an updated emacs
can cause it to crash.

I suggest we provide a way to recompile all .el files for elisp add-on
packages (typically from the app-emacs/ category, but also from
ebuilds supporting the emacs USE flag).  This mechanism should be
called whenever a new emacs upgrade is performed.

We should probably keep a separate source archive directory somewhere
so we can compile for multiple emacs implementations
(eg. app-editors/emacs and app-editors/emacs-cvs).  We should take
whatever steps are necessary to ensure find-function/variable/library
etc. still work properly.

* emacs and emacs-cvs coexistence

Following on from the previous point, it would be nice to clean up
app-editors/emacs and app-editors/emacs-cvs so they co-exist more
cleanly. (provide and /usr/bin/emacs and a /usr/bin/emacs-cvs -- I
know there's already a version number symlink there).

* Your Thoughts Here...


Matt

-- 
Matthew Kennedy
Gentoo Linux Developer

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] (emacs) proposed site-lisp and byte-compilation improvements

[Spider]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

Gratious use of email for nothing lest than spam...

begin  quote
On Sun, 16 Nov 2003 17:33:14 -0600
Matthew Kennedy <mkennedy@gentoo.org> wrote:



> 
> * Your Thoughts Here...

....  deprecate emacs in favour of vi ;)



Nah, overall your points are good, how do they work with 
xemacs/gnu emacs though?

//Spider

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] (emacs) proposed site-lisp and byte-compilation improvements

[Jeremy Maitin-Shepard]

Matthew Kennedy <mkennedy@gentoo.org> writes:
> In no particular order, here are some other changes I propose:

> * Move away from the big concatenation of
>   /usr/share/emacs/site-lisp/*-gentoo.el into
>   /usr/share/site-lisp/site-start.el.

> Instead, leave site-start.el alone, and create a site-gentoo.el which
> loads each *-gentoo.el file (call these "site hooks") pragmatically.
> This has the benefit of freeing up site-start.el for user usage.  The
> programmatic approach also allows for the possibility of the user
> defining their own site hooks.

I think this is a good idea.  I think though that we need a more
explicit policy about what should be placed in these site initialization
files.  Specifically, things such as a (bbdb-initialize) and other such
things in the site init files worry me.  Perhaps we should have several
different levels of initialization files.  For example, we could have
one file (per package) that only sets the load path and specifies
autoloads.  We could even provide in elisp-common.eclass a system for
generating such load path and autoload specifications (rather than
requiring that a separate file be included in the files directory).
Then, for each package there can be another site initialization file
that does additional things, like actually load certain packages (or in
the case of bbdb, initialize it).  It might be useful to also create a
/etc/skel/.emacs.el and a default.el that loads site-gentoo.el.

> * Byte-Compile site-gentoo.el and all site hooks

> Perhaps this will make for more rapid load times.

Good idea.

> * Install elisp source in such a way that global recompilation is
>   possible.

Good idea.  Perhaps we can just do:
find /usr/share/emacs/site-lisp -name \*.el -exec emacs -batch -f \
batch-byte-compile ... {} \;

> We should probably keep a separate source archive directory somewhere
> so we can compile for multiple emacs implementations
> (eg. app-editors/emacs and app-editors/emacs-cvs).  We should take
> whatever steps are necessary to ensure find-function/variable/library
> etc. still work properly.

Maybe /var/cache/site-lisp/<emacs-version>

> * emacs and emacs-cvs coexistence

> Following on from the previous point, it would be nice to clean up
> app-editors/emacs and app-editors/emacs-cvs so they co-exist more
> cleanly. (provide and /usr/bin/emacs and a /usr/bin/emacs-cvs -- I
> know there's already a version number symlink there).

This seems like a more general problem, that affects many packages.  I
suppose it nonetheless has to be solved for each package individually.
I suppose we could have /usr/bin/emacs-version and /usr/bin/emacs as a
symlink to the most recently installed version.  Or maybe create an
emacs-config tool that allows the system admin and each user to select
the desired version.

As far as such a tool, I think we should also provide tools for
regenerating site-lisp.el (or site-gentoo.el) and the various other
files that will be generated in the new system.  Additionally, if we
change the system for byte compiling, we should provide a tool to
re-byte compile the packages.  This could all go in an elisp-config
package.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: (emacs) proposed site-lisp and byte-compilation improvements

[Mamoru KOMACHI]

Hi,

At Sun, 16 Nov 2003 17:33:14 -0600,
Matthew Kennedy wrote:

> * Firstly, please review this: 
> 
>    http://dev.gentoo.org/~mkennedy/emacs/site-gentoo.el-rfc.txt

I'll second it. It will also solve http://bugs.gentoo.org/show_bug.cgi?id=10742

> * Install elisp source in such a way that global recompilation is
>   possible.

> I suggest we provide a way to recompile all .el files for elisp add-on
> packages (typically from the app-emacs/ category, but also from
> ebuilds supporting the emacs USE flag).  This mechanism should be
> called whenever a new emacs upgrade is performed.

I think the feature what you suggest here is not emacs specific but
global. For example, when people bumped openssl version 0.9.6 to 0.9.7
we saw many breakages and needed to run revdep-rebuild by hand.
However, if we had a variable in ebuild that tells Portage "all
the ebuilds that depend on me should be compiled again after emerge"
we wouldn't come across the problem. If this feature is implemented
into Portage we will have no problem not only with ebuilds in
app-emacs but also with other ebuilds supporting emacs USE flag
(because such ebuilds depend on virtual/emacs).

> * Your Thoughts Here...

I wonder why we don't have xemacs herd. Some of the bugs in bugzilla
were assigned to emacs@g.o after the alias was created, but I think
xemacs herd should be created and these bugs will be assigned to that
herd. There are two reasons for it. First, as I see from ChangeLogs in
app-xemacs category, xemacs packages are maintained by agriffis,
rendhalver and rac (they don't commit to app-emacs and those who
commit to app-emacs don't touch app-xemacs). Second, FSF Emacs and
XEmacs have different packaging policy and should be considered
separetely (I'm not using XEmacs, so I should ask XEmacs people before
I do any changes if it is assigned to emacs herd). We could have
meta-emacs herd to which both emacs and xemacs herd belong, but that
will be a different issue we might consider after creating xemacs
herd.

Any comments?

-- 
Mamoru KOMACHI <usata@gentoo.org>
http://www.gentoo.org/~usata/

--
gentoo-dev@gentoo.org mailing list