4. Adding Modules to the XEmacs Distribution

#### 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 objs on HAVE_SHLIB. The right way to do this is somewhat indirect. Study the integration of LDAP and PostgreSQL for the details.

This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.