What can I say? I apparently like talking to myself...
I wrote:
I wrote about scripts for finding miscompiled macros. Almost all of
them turned out to be bugs in the build process, or missing requires, or
somebody thinking that (require 'foo) inside a function makes foo load
at compile time. I will send a patch as soon as I get a chance to try
building my patched tree to see if I fixed everything, or if possibly
some of the macros expand to expressions containing other macros that
won't expand properly.....
Well, this is turning out to be more difficult than I expected. I had
to add some build time dependencies to make macros available at the
right times and places, and now I have dependency cycles. For example:
1) gnus contains gnus-util.el, which uses the macro
rmail-select-summary, so it requires rmail
2) rmail contains rmail.el, which requires tm-view, so it requires tm
3) tm contains bunches of stuff that require things in gnus
And that isn't the only cycle. How should I handle them? I would just
ignore them and hope that the right thing happened, but somehow I have
reached a state where the build process ends thusly:
xemacs -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error t
load-ignore-out-of-date-elc-files t load-show-full-path-in-messages t)' -l
/usr/src/xemacs/packages/package-compile.el -- gnus w3 mh-e mailcrypt rmail eterm mail-lib
xemacs-base fsf-compat ecrypto tm apel -- -f batch-byte-compile gnus/lisp/earcon.el
Loading /usr/local/lib/xemacs-21.4.10/lisp/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/apel/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/tm/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/ecrypto/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/fsf-compat/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/xemacs-base/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/mail-lib/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/eterm/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/rmail/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/mailcrypt/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/mh-e/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/w3/lisp/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/gnus/gnus/lisp/auto-autoloads...
Compiling /usr/src/xemacs/packages/xemacs-packages/gnus/gnus/lisp/earcon.el...
>Error occurred processing gnus/lisp/earcon.el:
Variable
binding depth exceeds max-specpdl-size
Done
make[2]: *** [gnus/lisp/earcon.elc] Error 1
make[2]: Leaving directory `/usr/src/xemacs/packages/xemacs-packages/gnus'
make[1]: *** [gnus/bytecompile.target] Error 2
make[1]: Leaving directory `/usr/src/xemacs/packages/xemacs-packages'
make: *** [xemacs-packages/bytecompile.target] Error 2
It looks like an infinite (require 'foo) recursion somewhere, because
this didn't happen until I started adding compile-time requires. Whee!
Is there a general rule for handling circular dependencies like this?
--
Jerry James
http://www.ittc.ku.edu/~james/