Problem making bindist of ruby-modes

Asfand Yar Qazi writes: Oops, I forgot to explain about that. Because I'm writing a developers' manual, I'll go into great detail, perhaps more than you want.:-) Theory: Lisp provides *macros*, which involve *expansion*, which means evaluating a Lisp expression which constructs a new Lisp expression. The second expression is then applied to the actual arguments to give the actual result. This means that expansion can take place without knowing the actual arguments. The most important example is at compile time. *Compiled code cannot expand macros*, so you must have all definitions of macros used available at compile time. The *defsubst* is like C "inline"; it's advice to the compiler, but the function can be called in the usual way. So although it's not strictly necessary, it's desirable for efficiency that defsubst definitions be available. Since Lisp is very dynamic, it's possible to for code to call functions that haven't been defined yet, as long as the call isn't evaluated until after the function definition is loaded. The autoload facility allows definitions to be loaded the first time they are used. Practice: When a package is built, of course its Lisp libraries are compiled. To ensure that necessary definitions are available, the libraries of the packages named in the REQUIRES Make variable are required, and the autoload definitions are loaded from generated libraries called "auto-autoloads" in each package. So you should at least do "make autoloads" from the top of the package tree. (I believe it's possible to do a more minimal set of auto-autoloads, just the ones that your package and packages it depends on use, but there's no automatic way to compute that set. In your case ruby-modes depends on xemacs-base and debug, debug depends on xemacs-base, and xemacs-base has no dependencies, so probably you only need to do make autoloads in those two packages.) Since the compile process involves expanding macros, which is executing package code, it will speed up the build process for your package to do a full "make" from the top (or at least a make of those two packages, first xemacs-base then debug). I don't know if the speedup is measurable, since make itself and simply starting XEmacs to do the compilation are pretty time-consuming. For the future: We know this is annoying, but disk space is cheap, and the requirement for a full build is a one-time thing. After that, you can just do make bindist in your package's directory. Suggestions for improvement of the process *are* welcome, but they must account for the need to provide macro definitions and autoloads. Some attempts have been made to track the dependencies on macros and autoloads, but the problem turns out to be fairly hard because it's possible to dynamically compute the names of functions to call, and things like that. Thus a program to analyze dependencies must actually understand Lisp semantics. We've found it most reliable to just build the packages, and set up dependencies when errors occur.:-/ HTH _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta