Asfand Yar Qazi writes:
Cannot open load file:
Oops, I forgot to explain about that. Because I'm writing a
developers' manual, I'll go into great detail, perhaps more than you
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.
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
XEmacs-Beta mailing list