Re: Automated package dependencies
Well, I'm glad people were paying attention after all. I was starting
to feel like a guy at a party who is telling a joke and gets to the
punchline, only to discover that everybody else left to go get a beer.
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Why an eval-when? require is already specially treated at compile
time. Just require the file and be done with it.
But only at top-level, apparently. The miscompiled defadvice in ffap.el
immediately follows a (require 'advice), but it is not at top-level. If
you look at ffap.elc, you'll see that the require is compiled in there
all right, so it will be executed at run time. However, the defadvice
macro is compiled as a function call, so the require clearly did not
take effect at compile time.
Also, some of the miscompiled macros I'm seeing are taken care of with a
require at compile time, but there is no run time dependency on the file
containing the macro. Doing an (eval-when-compile (require 'foo)) makes
perfect sense in that case.
Jeff> If the macro expands into functions then you might need
Jeff> autoload cookies for those functions.
Ugh. That's really ugly. No. Just require and be done with it.
Some of the miscompiled macros have autoload cookies already, but the
containing package was not in the REQUIRES list. I've just added to
REQUIRES in those cases.
Jeff> If you do all provides first, then requires, you will
not
Jeff> get infinite recursion.
And IIRC this is not harmful, in the sense that when loading XEmacs
records provides, and if the load fails for some reason, the provides
are undone.
That is correct. I'll have to move some provides then. I hadn't
thought about defsubsts, either, so I'll deal with those once I get the
macros to settle down and behave correctly. Keep watching for a patch.
I'll get a successful compile one of these days...
--
Jerry James
http://www.ittc.ku.edu/~james/