[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

7. XEmacs from the Perspective of Building

The heart of XEmacs is the Lisp environment, which is written in C. This is contained in the ‘src/’ subdirectory. Underneath ‘src/’ are two subdirectories of header files: ‘s/’ (header files for particular operating systems) and ‘m/’ (header files for particular machine types). In practice the distinction between the two types of header files is blurred. These header files define or undefine certain preprocessor constants and macros to indicate particular characteristics of the associated machine or operating system. As part of the configure process, one ‘s/’ file and one ‘m/’ file is identified for the particular environment in which XEmacs is being built.

XEmacs also contains a great deal of Lisp code. This implements the operations that make XEmacs useful as an editor as well as just a Lisp environment, and also contains many add-on packages that allow XEmacs to browse directories, act as a mail and Usenet news reader, compile Lisp code, etc. There is actually more Lisp code than C code associated with XEmacs, but much of the Lisp code is peripheral to the actual operation of the editor. The Lisp code all lies in subdirectories underneath the ‘lisp/’ directory.

The ‘lwlib/’ directory contains C code that implements a generalized interface onto different X widget toolkits and also implements some widgets of its own that behave like Motif widgets but are faster, free, and in some cases more powerful. The code in this directory compiles into a library and is mostly independent from XEmacs.

The ‘etc/’ directory contains various data files associated with XEmacs. Some of them are actually read by XEmacs at startup; others merely contain useful information of various sorts.

The ‘lib-src/’ directory contains C code for various auxiliary programs that are used in connection with XEmacs. Some of them are used during the build process; others are used to perform certain functions that cannot conveniently be placed in the XEmacs executable (e.g. the ‘movemail’ program for fetching mail out of ‘/var/spool/mail’, which must be setgid to ‘mail’ on many systems; and the ‘gnuclient’ program, which allows an external script to communicate with a running XEmacs process).

The ‘man/’ directory contains the sources for the XEmacs documentation. It is mostly in a form called Texinfo, which can be converted into either a printed document (by passing it through TeX) or into on-line documentation called info files.

The ‘info/’ directory contains the results of formatting the XEmacs documentation as info files, for on-line use. These files are used when you enter the Info system using C-h i or through the Help menu.

The other directories contain various miscellaneous code and information that is not normally used or needed.

The first step of building involves running the ‘configure’ program and passing it various parameters to specify any optional features you want and compiler arguments and such, as described in the ‘INSTALL’ file. (You may optionally run ‘autoconf’ first to update the ‘configure’ script. See section Modules for Build Configuration.) This determines what the build environment is, chooses the appropriate ‘s/’ and ‘m/’ file, and runs a series of tests to determine many details about your environment, such as which library functions are available and exactly how they work. Running these tests allows XEmacs to be compiled on a much wider variety of platforms than those that the XEmacs developers happen to be familiar with, including various sorts of hybrid platforms. This is especially important now that many operating systems give you a great deal of control over exactly what features you want installed, and allow for easy upgrading of parts of a system without upgrading the rest. It would be impossible to pre-determine and pre-specify the information for all possible configurations.

Thus, the ‘s/’ and ‘m/’ files are basically evil, since they contain platform-specific hard-coded information. XEmacs is moving in the direction of having all system-specific information be determined dynamically by ‘configure’. Perhaps someday we can rm -rf src/s src/m.

configure’ also parses the version information from ‘version.sh’ and adds it to ‘config.h’ as C preprocessor macros. These macros in turn are used to initialize some Lisp variables, such as ‘emacs-version’. See section The version.sh Script.

When configure is done running, it generates ‘Makefile’s and ‘GNUmakefile’s and the file ‘src/config.h’ (which describes the features of your system) from template files. You then run ‘make’, which compiles the auxiliary code and programs in ‘lib-src/’ and ‘lwlib/’ and the main XEmacs executable in ‘src/’. The result of compiling and linking is an executable called ‘temacs’, which is not the final XEmacs executable. ‘temacs’ by itself is not intended to function as an editor or even display any windows on the screen, and if you simply run it, it will exit immediately. The ‘Makefile’ runs ‘temacs’ with certain options that cause it to initialize itself, read in a number of basic Lisp files, and then dump itself out into a new executable called ‘xemacs’. This new executable has been pre-initialized and contains pre-digested Lisp code that is necessary for the editor to function (this includes most basic editing functions, e.g. kill-line, that can be defined in terms of other Lisp primitives; some initialization code that is called when certain objects, such as frames, are created; and all of the standard keybindings and code for the actions they result in). This executable, ‘xemacs’, is the executable that you run to use the XEmacs editor.

Although ‘temacs’ is not intended to be run as an editor, it can, by using the incantation temacs -batch -l loadup.el run-temacs. This is useful when the dumping procedure described above is broken, or when using certain program debugging tools such as Purify. These tools get mighty confused by the tricks played by the XEmacs build process, such as allocating memory in one process, and freeing it in the next.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

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