Re: Automated package dependencies

R> seems like we need to get the lisp these kind of loopy R> dependancies use into a common package ( xemacs-base ? ) so we R> can have the packages that require them all point to one R> package instead of each other in really bizzare ways You can have that "common package", today. It's called "GNU Emacs". It even includes our biggest REQUIRE'able, Gnus. ;-) Seriously, I think you'll find that the transitive closure of these loopy dependencies is a pretty big chunk of our packages. R> think shared lisp library. All Lisp libraries are shared in that sense. Remember that most Lisp libraries are all declaration/definition; not very much code is executed at load time. (That's inaccurate, in fact things like defun are often defined in Lisp, but it's close enough.) For the problems we're dealing with in REQUIRES, we never want compiled Lisp, either. Macros and defsubsts are open-coded in Lisp, then their callers are compiled. So in the build process, we just need to get lots and lots of Lisp definitions loaded, but only the macros and the defsubsts. (And in fact the defsubsts don't _need_ to be loaded at compile time, because they provide a regular defun so that a defsubst is funcall'able. But that defeats the purpose of a defsubst. We do want them available if at all possible.) Circularities are not an issue at compile time. The issues of "what packages do we _need_ at run time" are important, but they should be handled by a different mechanism from REQUIRES. How about SUGGESTS? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.