|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
#### This section needs to be filled out.
Warning: The procedure described in the section is subject to change, as it is very stylized and thus a good candidate for further automation.
Modules distributed with XEmacs are placed in the `modules' subdirectory of the root of the source tree. Each module's code is placed in a separate subdirectory. The build infrastructure for a module consists of a `Makefile.in.in', a `configure.ac', and `install-sh'. `install-sh' is a constant, and may simply be copied from an existing module.
Most of the job of building a module is encapsulated in `modules/common/Makefile.common' and in `ellcc'. The module's `Makefile.in.in' normally needs only to define module name and version information, and include `modules/common/Makefile.common'. The `configure.ac' is very module-specific, and little can be said about its contents. However, since no logic that depends on XEmacs itself or other modules needs to be present, it is easier to write and maintain than if it were contained in the XEmacs distribution's `configure.ac'.
Modules can usually be trivially built in to the XEmacs binary. To make
this work, you need to duplicate the detection logic for any resources
the module requires in the top-level `configure.ac'. Since module
objects may be linked into modules or into `xemacs', instead of
adding library path and library information directly to some
`subsystem_libs' variable, you should add them to a
`module_libs' variable, which in turn must be added to
ld_libs_module in the section "Compute SUBST-itutable variables."
Furthermore, in `src/Makefile.in.in' you add rules to build the
object without the module wrapper, and conditionalize these and the
addition of the object to
HAVE_SHLIB. The right
way to do this is somewhat indirect. Study the integration of LDAP and
PostgreSQL for the details.
|[ << ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|