4 SXEmacs From the Perspective of Building

The heart of SXEmacs 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 SXEmacs is being built.

SXEmacs also contains a great deal of Lisp code. This implements the operations that make SXEmacs useful as an editor as well as just a Lisp environment, and also contains many add-on packages that allow SXEmacs 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 SXEmacs, 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 SXEmacs.

The etc/ directory contains various data files associated with SXEmacs. Some of them are actually read by SXEmacs 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 SXEmacs. Some of them are used during the build process; others are used to perform certain functions that cannot conveniently be placed in the SXEmacs 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 SXEmacs process).

The man/ directory contains the sources for the SXEmacs 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 SXEmacs 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. 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. The reason for running these tests is that it allows SXEmacs to be compiled on a much wider variety of platforms than those that the SXEmacs 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.

In fact, the s/ and m/ files are basically evil, since they contain unmaintainable platform-specific hard-coded information. SXEmacs has been 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.

When configure is done running, it generates Makefiles and GNUmakefiles 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 SXEmacs executable in src/. The result of compiling and linking is an executable called temacs, which is not the final SXEmacs 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 SXEmacs 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 SXEmacs build process, such as allocation memory in one process, and freeing it in the next.