|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
This is a collection of random notes on build-time dependencies as of about XEmacs 21.5.11. Of course we use `make' to manage most dependencies, especially for the C code. The main thing here is for the Release Engineer to run the `src/make-src-depend' script every so often, at least at every release.
However, since most of XEmacs is written in Lisp, and we compile and preload the Lisp for efficiency, managing Lisp compilation using `make' would imply running XEmacs hundreds of times. This would make the build process unbearably long. Thus those processes that require running the same Lisp programs on many files are managed using Lisp driver functions rather than `make'. The situation is further complicated by the fact that documentation strings are kept in an external database, and referenced in the dumped XEmacs by file offset. Finally, the Lisp files are processed to collect autoloaded function information and customize dependencies, which are then written into generated Lisp files.
About this, Ben sez:
- Redumping depends on up-to-date dumped `.elc' files and `DOC' but not directly on auto-autoloads.
- Rebuilding dumped `.elc' files depends on auto-autoloads being up-to-date.
- Building the `DOC' file depends on up-to-date dumped `.elc' files but not directly on auto-autoloads.
- Recompiling anything depends on `bytecomp.elc' and `byte-optimize.elc' being up-to-date.
Put these together and you'll see it's perfectly acceptable to build auto-autoloads after dumping if no `.elc' files are out-of-date.
These Lisp driver programs typically run from temacs, not a dumped XEmacs. The simplest (but time-consuming) way to achieve a sane environment for running Lisp is to load `loadup.el' or `loadup-el.el'. (The latter is used to avoid loading possibly out-of-date compiled Lisp files.) If this is not done, you have to construct the environment yourself. See `dumped-lisp.el' to see how it is done in the dumped XEmacs.
One potential gotcha is that very early customizations are now handled
by adding the definitions to the special variable
custom-declare-variable-list, defined in `subr.el'. If you
use any higher-level functionality that might load `custom.el', but
you do not need `subr.el', you should `defvar'
custom-declare-variable-list to prevent the `void-variable'
error. (Currently this is only needed for `make-docfile.el'.)
|[ << ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|