Re: cvs removal of auto-autoloads.el and custom-loads.el
Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org:
I've just reversed Ben's change, since the Unix build was
broken with
this change, and I didn't want to leave it in its broken state for too
long.
Thanks.
The sad story appears to be that, just like a compiler that's
been incestuously compiling itself for too long, Unix XEmacs needs a
working auto-autoloads.el file to update the auto-autoloads.el file,
and I'm not up to fixing it tonight.
The very best fix would involve a rework of the entire build
structure.
Actually, it wouldn't. At a minimum, it would require a rewrite of
autoload.el to run out of temacs, so that one could insert an autoloads
generation step between creating temacs, and bytecompiling the dumped
lisp. This is a pain for various reasons. If we could zap the entire
interactive interface to autoloads generation it would be somewhat less
painful.
My preferred solution was to entirely zap autoloads from core lisp.
This doesn't solve the custom loads problem, however, custom-loads.el
isn't needed to get to an xemacs binary.