Mercurial > hg > xemacs-beta
annotate modules/README @ 1298:1b4bc72f433e
[xemacs-hg @ 2003-02-14 12:05:06 by ben]
speedups to build process
autoload.el: Factor out common code in generate-{c-,}file-autoloads-1 into new
function generate-autoload-ish-1. \(I was originally going to use
this for custom as well but ended up thinking better of it.)
cus-dep.el: Cache the old computed values in custom-load.el and reuse them as
necessary, to speed up running cus-dep (which would take 25-30
seconds to do all files in lisp/*, lisp/*/* on my Pentium III
700). Use `message' not `princ' to get correct newline behavior.
Output messages showing each file we do actually process.
update-elc-2.el: Rewrite algorithm to be much faster -- cache calls to
directory-files and don't make needless calls to file-exists-p,
file-directory-p because they're way way slow.
Autoload early and only when update-elc has told us to.
update-elc.el: If no files need byte compilation, signal to update-elc-2 to do
any necessary autoload updating (using the file REBUILD_AUTOLOADS)
rather than doing it ourselves, which would be way slow. Ignore
updates to custom-load.el and auto-autoloads.el when checking to
see whether autoloads need updating. Optimize out many
unnecessary calls to file-exists-p to speed it up somewhat. (####
The remaining time is 50% or more in locate-file; this is
presumably because, even though it has a cache, it's still
statting each file to determine it's actually there. By calling
directory-files ourselves, building a tree, and then looking in
that tree, we could drastically shorten the time needed to do the
locate operation.)
| author | ben |
|---|---|
| date | Fri, 14 Feb 2003 12:05:07 +0000 |
| parents | 25e260cb7994 |
| children | da1365dd3f07 |
| rev | line source |
|---|---|
| 996 | 1 This directory contains a number of XEmacs dynamic modules. These |
| 2 modules can be loaded directly with the command 'M-x load-module'. | |
| 3 However, the preferred method of loading a module is to issue a | |
| 4 "(require 'module-name)" command to the Lisp interpreter. This will | |
| 5 store information so that a later "(unload-feature 'module-name)" can | |
| 6 succeed. | |
| 388 | 7 |
| 996 | 8 To compile one of these modules, simply enter the desired directory, |
| 9 type 'configure', and then 'make'. If you are building the module for | |
| 10 an installed XEmacs, then 'make install' will place the module in the | |
| 11 appropriate directory for XEmacs to find it later (assuming you have | |
| 12 permission to write to that directory). A subsequent 'load-module' or | |
| 13 'require' will then load the module, as described above. | |
| 388 | 14 |
| 996 | 15 Each of these demonstrates different features and limitations of the |
| 16 XEmacs module loading technology. For a complete discussion on XEmacs | |
| 17 dynamic modules, please consult the XEmacs Module Writers Guide, which | |
| 18 can be found in the ../info directory. | |
| 388 | 19 |
| 996 | 20 For those wanting to get started with module writing, please see the |
| 21 'sample' directory. It contains two subdirectories: internal and | |
| 22 external. The 'internal' subdirectory contains the framework needed to | |
| 23 migrate some core piece of XEmacs functionality into code that can | |
| 24 either be compiled into the core or built as a separate module. The | |
| 25 'external' subdirectory contains the somewhat simpler framework needed | |
| 26 to build a module separately from XEmacs. These should be considered | |
| 27 starting places for module writing. |
