Re: Automated package dependencies
On 17 Dec 2002, scop(a)xemacs.org wrote:
On Tue, 2002-12-17 at 01:27, Jerry James wrote:
> What can I say? I apparently like talking to myself...
FWIW, it was a pretty clever idea.
Files using macros defined in other files should require those files
inside of an eval-when?
(eval-when (compile) (require 'macro-file))
If the macro expands into functions then you might need autoload
cookies for those functions.
I like listening, don't consider (equal silence ignorance) :)
Seriously, your efforts are really appreciated, but unfortunately
providing any sensible comments about this stuff is beyond my lisp
knowledge. "Makes sense to me" is about the best I can do :/
> 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
Aren't this kind of cycles automatically dropped? ISTR seeing some
messages about detected and dropped dep cycles somewhere when building
packages. Ah, but that must have been for REQUIRES in Makefiles...
> 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?
Dunno, but how's about using something like this to prevent it?
(or (featurep 'foo) (require 'foo))
require (defined in src/fns.c) already does a featurep check (both
featurep and require do memq on the features list).
The ordering of require and provide statements can cause recursions.
Here is a simple way to reproduce recursion:
foo.el:
-----
(require 'bar)
(provide 'foo)
-----
bar.el:
-----
(require 'foo)
(provide 'bar)
-----
Then do:
(require 'foo)
If you do all provides first, then requires, you will not get infinite recursion.
-jeff