Next: Control Files, Up: The Library Maintainer View [Contents][Index]
In order to get the greatest benefit from the XEmacs Packaging System, a library maintainer should place the package sources in an appropriate place in the XEmacs source package hierarchy, and arrange to have the source package imported into the XEmacs CVS repository. (We realize that the latter requirement can be quite burdensome. We are working on ways to remove this requirement, but for the present it remains necessary.) The library maintainer must also keep sources for any packages his/her package requires. This requirement is somewhat burdensome, but unlikely to be relaxed because of the implementation of compilation of macros in Emacs Lisp. Macros cannot be called by compiled Lisp (the macro expansion, which is always known at compile time, is inlined), so the source of the macro must be loaded before compiling the called function.
The source package hierarchy may be rooted anywhere. The CVS module is called “packages,” so we will refer to the top directory of the source package hierarchy as “the packages directory.” The packages directory contains two source subdirectories, xemacs-packages and mule-packages (for convenience in segregating the packages which depend on Mule, as they will cause load-time errors in a non-Mule XEmacs). Each subdirectory contains many package source directories, whose internal structure is not specified. That structure is left up to the convenience of the library maintainers. The requirements on the top directory of an individual package source tree are given below, Control Files.
The packages directory contains some auxiliary Lisp libraries used in the compilation and packaging process. The content of these libraries is of interest primarily to the packaging engineers, The Package Release Engineer View.
Finally, the packages, packages/xemacs-packages, and packages/mule-packages directories contain Makefiles and include files to control the package creation process. The Makefiles in packages/xemacs-packages and packages/mule-packages simply define the default sets of known packages and include ../iterate.rules, which implements recursive building of all target packages.
The ‘make’ infrastructure in packages includes
controls building of individual packages, local installation, and bundling of “sumo” tarballs
controls recursive builds of multiple packages
This is used by higher-level subdirectories that do not directly contain packages. Subdirectories directly containing packages should use iterate.rules instead.
provides the rules for building and packaging. Included by all package Makefiles.
provides local configuration, such as installation targets and staging directories, as well as a number of kludges (many now obsolete) required for building packages on the Windows platform.
a template for Local.rules, liberally commented
consistency checking for Local.rules, included by both the top-level Makefile and by XEmacs.rules.
a file to include in package Makefiles to be able to get
at variables in Local.rules before including
XEmacs.rules.
compile environment (e.g., load-path) setup.
Of these, only Local.rules and package-compile.el need to be modified by the library maintainer. The changes to Local.rules affect only your environment. This should need to be done only once when first preparing the source environment. The necessary modifications to package-compile.el need to be done for each package and are discussed in the next section, Control Files.
Next: Control Files, Up: The Library Maintainer View [Contents][Index]