>>>> "Ville" == Ville Skytt <Ville>
Ville> Yep, of course they're not. But listing all requirements,
Ville> direct and indirect/recursive, just shouldn't happen IMO.
Ville> When time passes and some of the package X's directly
Ville> required packages' requirements change, it will either lead
Ville> to missing/extra REQUIRES stuff in package X, or to
Ville> maintenance hell.
Er, no. That is not maintenance hell. _This_ is:
;; Here's a neat function.
+;; I think so, too, and it's really the only entry point.
+;; So let's autoload it and get rid of some #'requires...
(defun really-neat-function () ; ...
Charles Waldman did some work on generating a graph of dependencies.
You might search the archives (late 1999?). However, he did it in
Python, and this really should be done in Emacs Lisp (see below).
I think that all the necessary information is in the Makefile and
auto-autoloads.el ... oops, no, you do have to grep out all the
#'requires (Makefile REQUIRES is currently unreliable because
I think a two-pass algorithm which first goes through all the files
and greps out all autoloaded symbols (watch out for eval-when
constructs and the like; defuns and defvars will not necessarily be at
top level), then checks for dependencies, is sufficient.
Pass 2 should be done by the byte compiler (hook in to the places
where we check for whether a variable is defined/used). Pass 1 should
result in an auxiliary hashtable of symbols which says what they are
and where they are defined. Probably this can be done by
`batch-update-autoloads' et al.
Ville> Splitting packages into smaller chunks should help with
Ville> this too.
I think it actually hurts, by increasing the number of possible (and
actual) transitive dependencies.
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py