Sean Champ <junctionxyz(a)mediaone.net> writes:
apel-ver requires product, which requires pym, which requires
apel-ver
It's worse, pym itself requires product. The APEL setup actually makes
use of the fact that the macros that pym needs are in fact provided
by product before it does a (provide 'product) and a (require 'pym).
OUCH!.
looking at it, i wonder how the heck any of 'em gets loaded in the
first place, and I don't C well enough to make sense of how 'require'
works.
1) so, which of those three gets loaded first? and how does the reader
know when to return from the loop?
A quick glance seems to indicate (I haven't verified) the load or
order is
apel-ver upto (require 'product)
product (upto require 'pym)
pym
apel-ver (from the top again).
pym (cont'd)
product (cont'd)
apel-ver (cont'ed)
i.e. apel-ver gets loaded twice if I am not mistaken.
The reason the reader gets out of it is because the reader read the
file form by form recursively. By the time apel-ver gets required
again by pym, product.el already had done a 'provide'.
apel-ver is loaded twice though.
That is why in general you should put a provide as the very first form
in your source file. [Although one could argue macro defs should come
before, but then IMHO those are better put in a separate .el file]
2) do you have any suggestions, on how i should avoid an endless
iteration in that loop of feature-file requirements?
There is no way you can 100% reproduce the behavior of the reader from
just the static data. The best thing you can do is detect the loop
(say by storing the includer includee pairs)
Jan