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
> 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
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.