[3992] in testers

home help back first fref pref prev next nref lref last post

Re: vc in emacs

daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun May 2 11:06:21 1999

Message-Id: <199905021506.LAA00599@nephthys.grey17.org>
To: Jeremy Daniel <jdaniel@MIT.EDU>
cc: testers@MIT.EDU
In-reply-to: Your message of "Sun, 02 May 1999 04:10:03 EDT."
             <199905020810.EAA24942@maleficent.mit.edu> 
Date: Sun, 02 May 1999 11:06:11 EDT
From: Greg Hudson <ghudson@MIT.EDU>

> Explicitly loading the non-compiled version seems to make it work
> happily.  So it looks like you just need to recompile this file, but
> how it ended up this way I'm kinda curious.

emacs doesn't actually rebuild the .elc files during compilation; the
shipped .elc files are assumed to be correct.  (I think this whole
system is bogus; it dramatically increases the size of the source
distribution, complicates importing emacs into CVS because of RCS IDs,
masks bugs in the .el files, and creates situations precisely like
this one, all to save a little time during the build process.)

We don't modify very many .el files (vc-hooks.el and info.el), and for
emacs 20.3 we simply forgot to recompile them.  For the last packs
rebuild, I found the problem after doing the build, recompiled the
file, updated /mit/source, and rebuilt and reinstalled emacs.  I
forgot, though, that we don't make a link farm under
/build/third/emacs/lisp; we make a copy (because emacs installs the
lisp directory using "tar", another bogus aspect of the build system).
So my fix didn't get propagated.

The problem will be fixed for real in the next packs rebuild (along
with info.elc), which should be today but I think will be delayed a
little bit because I'm waiting for Mike to import new lprng code.

home help back first fref pref prev next nref lref last post