"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Seems to be mildly broken.
You know, it's really hard for me to cultivate an air of infallibility
when you guys keep finding bugs in my code.
auto-autoloads.el* are generated in $srcdir/modules/, not
I did this on purpose, because the installed XEmacs doesn't have any
subdirectories under "modules". All of the .ell files are in the same
directory, so that's where the (sole) autoload file needs to go. You
are correct in pointing out that this breaks run-in-place, however.
module-load-path ends up being "$blddir/modules/".
That was true before I came along. I just haven't done anything about
it. What should happen is that run-in-place sets module-load-path in a
manner analogous to how load-path is set for the installed XEmacs; i.e.,
every subdirectory of $blddir/modules is added to module-load-path. Now
that I think about it, it would work to add every subdirectory now, as
long as the top-level directory is in module-load-path, too. For the
installed XEmacs, this is right because there aren't any subdirectories,
so only the top-level directory appears. For run-in-place, this is
right even though we get the useless top-level directory entry. I'll
whip up a patch this weekend.
It would be nice if zlib and base64 were detected by toplevel
configure and added to MAKE_SUBDIR.
They aren't ready for prime-time yet. Those modules predate me, and
have the appearance of never quite having been finished. Take a look at
zlib.c, for example. Looks useful, eh? The base64 code is closer to
being something useful, but ...
What happens if both Gnus and modules/base64 provide
Which wins? Does list-load-path-shadows detect these as shadows?
... we don't need it, unless the Gnus version is abysmally slow.
Shadows are a problem. It appears that list-load-path-shadows is only
checking filenames along load-path, so it would not detect such a
problem. As for which one wins, that depends on the order in which
autoloads are loaded. If you look in startup.el (end of the file),
you'll see that module autoloads are loaded first, then package
autoloads. This means that Gnus would win; the base64 module would
never get loaded unless the user explicitly loaded it with load-module.
That's a good thing, IMO. You get the Lisp code unless you explicitly
ask for the (hopefully equivalent) C code, presumably in response to