-This is ../info/emodules.info, produced by makeinfo version 4.0 from
+This is ../info/emodules.info, produced by makeinfo version 4.8 from
emodules.texi.
This file documents the module loading technology of XEmacs.
* Menu:
* Introduction:: Introducing Emacs Modules
-* Annatomy of a Module:: Basic module layout and technology
+* Anatomy of a Module:: Basic module layout and technology
* Using ellcc:: How to use the module compiler
* Defining Functions:: Creating new Lisp primitives
* Defining Variables:: Creating new Lisp variables
--- The Detailed Node Listing ---
-Annatomy of a Module
+Anatomy of a Module
* Required Header File:: Always include <emodules.h>
* Required Functions:: Functions you must always provide
* Required Variables:: Variables whose values you must provide
-* Loading other Modules:: How to load dependant modules
+* Loading other Modules:: How to load dependent modules
Using `ellcc'
* Declaring Functions:: Declaring functions to the Lisp reader
\1f
-File: emodules.info, Node: Introduction, Next: Annatomy of a Module, Prev: Top, Up: Top
+File: emodules.info, Node: Introduction, Next: Anatomy of a Module, Prev: Top, Up: Top
-Introduction
-************
+1 Introduction
+**************
- XEmacs is a powerful, extensible editor. The traditional way of
+XEmacs is a powerful, extensible editor. The traditional way of
extending the functionality of XEmacs is to use its built-in Lisp
language (called Emacs Lisp, or Elisp for short). However, while Elisp
is a full programming language and capable of extending XEmacs in more
Firstly, Elisp is an interpreted language, and this has serious speed
implications. Like all other interpreted languages (like Java), Elisp
is often suitable only for certain types of application or extension.
-So although Elisp is a general purpose language, and very ligh level,
+So although Elisp is a general purpose language, and very high level,
there are times when it is desirable to descend to a lower level
compiled language for speed purposes.
low level access to a system or need to be as quick as possible.
This manual describes a new way of extending XEmacs, by using dynamic
-loadable modules (also knows as dynamicaly loadable libraries (DLLs),
-dynamic shared objects (DSOs) or just simply shared objectcs), which can
+loadable modules (also known as dynamically loadable libraries (DLLs),
+dynamic shared objects (DSOs) or just simply shared objects), which can
be written in C or C++ and loaded into XEmacs at any time. I sometimes
refer to this technology as "CEmacs", which is short for "C Extensible
Emacs".
XEmacs.
* CEmacs also makes all of the relevant XEmacs internal header
- files availible for module authors to use. This is often required
+ files available for module authors to use. This is often required
to get data structure definitions and external variable
declarations. The header files installed include the module
specific header file `emodules.h'. Due to the nature of dynamic
done.
\1f
-File: emodules.info, Node: Annatomy of a Module, Next: Using ellcc, Prev: Introduction, Up: Top
+File: emodules.info, Node: Anatomy of a Module, Next: Using ellcc, Prev: Introduction, Up: Top
-Annatomy of a Module
-********************
+2 Anatomy of a Module
+*********************
- Each dynamically loadable XEmacs extension (hereafter refered to as a
+Each dynamically loadable XEmacs extension (hereafter referred to as a
module) has a certain compulsory format, and must contain several
pieces of information and several mandatory functions. This chapter
describes the basic layout of a module, and provides a very simple
* Required Header File:: Always include <emodules.h>
* Required Functions:: Functions you must always provide
* Required Variables:: Variables whose values you must provide
-* Loading other Modules:: How to load dependant modules
+* Loading other Modules:: How to load dependent modules
\1f
-File: emodules.info, Node: Required Header File, Next: Required Functions, Prev: Annatomy of a Module, Up: Annatomy of a Module
+File: emodules.info, Node: Required Header File, Next: Required Functions, Prev: Anatomy of a Module, Up: Anatomy of a Module
-Required Header File
-====================
+2.1 Required Header File
+========================
- Every module must include the file `<emodules.h>'. This will
-include several other XEmacs internal header files, and will set up
-certain vital macros. One of the most important files included by
-`emodules.h' is the generated `config.h' file, which contains all of
-the required system abstraction macros and definitions. Most modules
-will probably require some pre-processor conditionals based on
-constants defined in `config.h'. Please read that file to familiarize
-yourself with the macros defined there.
+Every module must include the file `<emodules.h>'. This will include
+several other XEmacs internal header files, and will set up certain
+vital macros. One of the most important files included by `emodules.h'
+is the generated `config.h' file, which contains all of the required
+system abstraction macros and definitions. Most modules will probably
+require some pre-processor conditionals based on constants defined in
+`config.h'. Please read that file to familiarize yourself with the
+macros defined there.
Depending on exactly what your module will be doing, you will
probably need to include one or more of the XEmacs internal header
variable declarations.
`sysdep.h'
- All system dependant declarations and abstraction macros live
+ All system dependent declarations and abstraction macros live
here. You should never call low level system functions directly.
Rather, you should use the abstraction macros provided in this
header file.
manipulating XEmacs frames.
\1f
-File: emodules.info, Node: Required Functions, Next: Required Variables, Prev: Required Header File, Up: Annatomy of a Module
+File: emodules.info, Node: Required Functions, Next: Required Variables, Prev: Required Header File, Up: Anatomy of a Module
-Required Functions
-==================
+2.2 Required Functions
+======================
- Every module requires several initialization functions. It is the
-responsibility of these functions to load in any dependant modules, and
-to declare all variables and functions which are to be made visibile to
+Every module requires several initialization functions. It is the
+responsibility of these functions to load in any dependent modules, and
+to declare all variables and functions which are to be made visible to
the XEmacs Lisp reader. Each of these functions performs a very
specific task, and they are executed in the correct order by XEmacs.
All of these functions are `void' functions which take no arguments.
`DEFVAR_LISP()', `DEFVAR_BOOL()' etc, and its purpose is to
declare and initialize all and any variables that your module
defines. They syntax for declaring variables is identical to the
- syntax used for all internal XEmacs source code.
+ syntax used for all internal XEmacs source code. If the module is
+ intended to be usable statically linked into XEmacs, the actions
+ of this function are severely restricted. *Note General Coding
+ Rules: (internals)General Coding Rules. Also see the comments in
+ `src/emacs.c' (`main_1'). Modules which perform initializations
+ not permitted by these rules will probably work, but dual-use
+ (dynamic loading and static linking) modules will require very
+ careful, and possibly fragile, coding.
`modules_of_module'
This optional function should be used to load in any modules which
functions and variables declared in your module.
\1f
-File: emodules.info, Node: Required Variables, Next: Loading other Modules, Prev: Required Functions, Up: Annatomy of a Module
+File: emodules.info, Node: Required Variables, Next: Loading other Modules, Prev: Required Functions, Up: Anatomy of a Module
-Required Variables
-==================
+2.3 Required Variables
+======================
- Not only does a module need to declare the initialization functions
+Not only does a module need to declare the initialization functions
mentioned above, it is also required to provide certain variables which
the module loading code searches for in order to determine the viability
of a module. You are _not_ required to provide these variables in your
This is a short (typically 10 characters or less) name for the
module, and it is used as a suffix for all of the required
functions. This is also the name by which the module is
- recognised when loading dependant modules. The name does not
+ recognized when loading dependent modules. The name does not
necessarily have to be the same as the physical file name,
although keeping the two names in sync is a pretty good idea. The
name must not be empty, and it must be a valid part of a C
module. The value is set by the `--mod-title' argument to `ellcc'.
\1f
-File: emodules.info, Node: Loading other Modules, Prev: Required Variables, Up: Annatomy of a Module
+File: emodules.info, Node: Loading other Modules, Prev: Required Variables, Up: Anatomy of a Module
-Loading other Modules
-=====================
+2.4 Loading other Modules
+=========================
- During the loading of a module, it is the responsibility of the
-function `modules_of_module' to load in any modules which the current
-module depends on. If the module is stand-alone, and does not depend
-on other modules, then this function can be left empty or even
-undeclared. However, if it does have dependnacies, it must call
-`emodules_load':
+During the loading of a module, it is the responsibility of the function
+`modules_of_module' to load in any modules which the current module
+depends on. If the module is stand-alone, and does not depend on other
+modules, then this function can be left empty or even undeclared.
+However, if it does have dependencies, it must call `emodules_load':
- int emodules_load (CONST char *module,
- CONST char *modname,
- CONST char *modver)
+ int emodules_load (const char *module,
+ const char *modname,
+ const char *modver)
The first argument MODULE is the name of the actual shared object or
DLL. You can omit the `.so', `.ell' or `.dll' extension of you wish.
their parents will also fail to load. This does not include previous
successful calls to `emodules_load' at the top level.
+ *Warning:* Modules are _not_ loaded with the `RTLD_GLOBAL' flag.
+The practical upshot is that individual modules do not have access to
+each other's C symbols. One module cannot make a C function call to a
+function defined in another module, nor can it read or set a C variable
+in another module. All interaction between modules must, therefore,
+take place at the Lisp level. This is by design. Other projects have
+attempted to use `RTLD_GLOBAL', only to find that spurious symbol name
+clashes were the result. Helper functions often have simple names,
+increasing the probability of such a clash. If you really need to
+share symbols between modules, create a shared library containing those
+symbols, and link your modules with that library. Otherwise,
+interactions between modules must take place via Lisp function calls
+and Lisp variables accesses.
+
\1f
-File: emodules.info, Node: Using ellcc, Next: Defining Functions, Prev: Annatomy of a Module, Up: Top
+File: emodules.info, Node: Using ellcc, Next: Defining Functions, Prev: Anatomy of a Module, Up: Top
-Using `ellcc'
-*************
+3 Using `ellcc'
+***************
- Before discussing the anatomy of a module in greater detail, you
-should be aware of the steps required in order to correctly compile and
-link a module for use within XEmacs. There is little difference between
+Before discussing the anatomy of a module in greater detail, you should
+be aware of the steps required in order to correctly compile and link a
+module for use within XEmacs. There is little difference between
compiling normal C code and compiling a module. In fact, all that
changes is the command used to compile the module, and a few extra
arguments to the compiler.
\1f
File: emodules.info, Node: Compile Mode, Next: Initialization Mode, Prev: Using ellcc, Up: Using ellcc
-Compile Mode
-============
+3.1 Compile Mode
+================
- By default, `ellcc' is in "compile" mode. This means that it
-assumes that all of the command line arguments are C compiler arguments,
-and that you want to compile the specified source file or files. You
-can force compile mode by specifying the `--mode=compile' argument to
+By default, `ellcc' is in "compile" mode. This means that it assumes
+that all of the command line arguments are C compiler arguments, and
+that you want to compile the specified source file or files. You can
+force compile mode by specifying the `--mode=compile' argument to
`ellcc'.
In this mode, `ellcc' is simply a front-end to the same C compiler
some appropriate place something similar to:
CC=ellcc --mode=compile
-
+
.c.o:
$(CC) $(CFLAGS) -c $<
\1f
File: emodules.info, Node: Initialization Mode, Next: Link Mode, Prev: Compile Mode, Up: Using ellcc
-Initialization Mode
-===================
+3.2 Initialization Mode
+=======================
- XEmacs uses a rather bizarre way of documenting variables and
+XEmacs uses a rather bizarre way of documenting variables and
functions. Rather than have the documentation for compiled functions
and variables passed as static strings in the source code, the
documentation is included as a C comment. A special program, called
The result of running `ellcc' in initialization mode is a C source
file which you compile with (you guessed it) `ellcc' in compile mode.
Initialization mode is where you set the module name, version, title
-and gather together all of the documentaion strings for the functions
-and vairables in your module. There are several options that you are
+and gather together all of the documentation strings for the functions
+and variables in your module. There are several options that you are
required to pass `ellcc' in initialization mode, the first of which is
the mode switch itself, `--mode=init'.
LD=ellcc --mode=link
MODINIT=ellcc --mode=init
CFLAGS=-O2 -DSOME_STUFF
-
+
.c.o:
$(CC) $(CFLAGS) -c $<
-
+
MODNAME=sample
MODVER=1.0.0
MODTITLE="Small sample module"
-
+
SRCS=modfile1.c modfile2.c modfile3.c
OBJS=$(SRCS:.c=.o)
-
+
all: sample.ell
clean:
rm -f $(OBJS) sample_init.o sample.ell
-
+
install: all
mkdir `ellcc --mod-location`/mymods > /dev/null
cp sample.ell `ellcc --mod-location`/mymods/sample.ell
-
+
sample.ell: $(OBJS) sample_init.o
$(LD) --mod-output=$ $(OBJS) sample_init.o
-
+
sample_init.o: sample_init.c
sample_init.c: $(SRCS)
$(MODINIT) --mod-name=$(MODNAME) --mod-version=$(MODVER) \
sample module, and optionally install it. The `--mod-location'
argument to `ellcc' will produce, on the standard output, the base
location of the XEmacs module directory. Each sub-directory of that
-directory is automatically searched for for modules when they are loaded
+directory is automatically searched for modules when they are loaded
with `load-module'. An alternative location would be
`/usr/local/lib/xemacs/site-modules'. That path can change depending
on the options the person who compiled XEmacs chose, so you can always
directory. Each sub-directory within it is searched for a given module
when the user attempts to load it. The valid extensions that the
loader attempts to use are `.so', `.ell' and `.dll'. You can use any
-of these extensions, although `.ell' is the prefered extension.
+of these extensions, although `.ell' is the preferred extension.
\1f
File: emodules.info, Node: Link Mode, Next: Other ellcc options, Prev: Initialization Mode, Up: Using ellcc
-Link Mode
-=========
+3.3 Link Mode
+=============
- Once all of your source code files have been compiled (including the
-generated init file) you need to link them all together to created the
+Once all of your source code files have been compiled (including the
+generated init file) you need to link them all together to create the
loadable module. To do this, you invoke `ellcc' in link mode, by
-pasing the `--mode-link' command. You need to specify the final output
-file using the `--mod-output=NAME' command, but other than that all
+passing the `--mode=link' option. You need to specify the final output
+file using the `--mod-output=NAME' option, but other than that all
other arguments are passed on directly to the system compiler or
linker, along with any other required arguments to create the loadable
module.
\1f
File: emodules.info, Node: Other ellcc options, Next: Environment Variables, Prev: Link Mode, Up: Using ellcc
-Other `ellcc' options
-=====================
+3.4 Other `ellcc' options
+=========================
- Aside from the three main `ellcc' modes described above, `ellcc' can
+Aside from the three main `ellcc' modes described above, `ellcc' can
accept several other options. These are typically used in a `Makefile'
to determine installation paths. `ellcc' also allows you to over-ride
several of its built-in compiler and linker options using environment
is displayed.
`--mod-name=NAME'
- Sets the short internaml module NAME to the string specified,
- which must consist only of valid C identifiers. Required during
+ Sets the short internal module NAME to the string specified, which
+ must consist only of valid C identifiers. Required during
initialization mode.
`--mod-version=VERSION'
exit.
`--mod-archdir'
- Prints the name of the root of the architecture-dependant
- directory that XEmacs searches for architecture-dependant files.
+ Prints the name of the root of the architecture-dependent
+ directory that XEmacs searches for architecture-dependent files.
`--mod-config'
Prints the name of the configuration for which XEmacs and `ellcc'
\1f
File: emodules.info, Node: Environment Variables, Prev: Other ellcc options, Up: Using ellcc
-Environment Variables
-=====================
+3.5 Environment Variables
+=========================
- During its normal operation, `ellcc' uses the compiler and linker
-flags that were determined at the time XEmacs was configured. In
-certain rare circumstances you may wish to over-ride the flags passed to
-the compiler or linker, and you can do so using environment variables.
-The table below lists all of the environment variables that `ellcc'
-recognises.
+During its normal operation, `ellcc' uses the compiler and linker flags
+that were determined at the time XEmacs was configured. In certain
+rare circumstances you may wish to over-ride the flags passed to the
+compiler or linker, and you can do so using environment variables. The
+table below lists all of the environment variables that `ellcc'
+recognizes.
`ELLCC'
This is used to over-ride the name of the C compiler that is
\1f
File: emodules.info, Node: Defining Functions, Next: Defining Variables, Prev: Using ellcc, Up: Top
-Defining Functions
-******************
+4 Defining Functions
+********************
- One of the main reasons you would ever write a module is to provide
-one or more "functions" for the user or the editor to use. The term
+One of the main reasons you would ever write a module is to provide one
+or more "functions" for the user or the editor to use. The term
"function" is a bit overloaded here, as it refers to both a C function
and the way it appears to Lisp, which is a "subroutine", or simply a
"subr". A Lisp subr is also known as a Lisp primitive, but that term
\1f
File: emodules.info, Node: Using DEFUN, Next: Declaring Functions, Prev: Defining Functions, Up: Defining Functions
-Using `DEFUN'
-=============
+4.1 Using `DEFUN'
+=================
- Although the full syntax of a function declaration is discussed in
-the XEmacs internals manual in greater depth, what follows is a brief
+Although the full syntax of a function declaration is discussed in the
+XEmacs internals manual in greater depth, what follows is a brief
description of how to define and implement a new Lisp primitive in a
module. This is done using the `DEFUN' macro. Here is a small example:
DEFUN ("my-function", Fmy_function, 1, 1, "FFile name: ", /*
Sample Emacs primitive function.
-
- The specified FILE is frobricated before it is fnozzled.
+
+ The specified FILE is frobnicated before it is fnozzled.
*/
(file))
{
char *filename;
-
+
if (NILP(file))
return Qnil;
-
+
filename = (char *)XSTRING_DATA(file);
frob(filename);
return Qt;
\1f
File: emodules.info, Node: Declaring Functions, Prev: Using DEFUN, Up: Defining Functions
-Declaring Functions
-===================
+4.2 Declaring Functions
+=======================
- Simply writing the code for a function is not enough to make it
-availible to the Lisp reader. You have to, during module
+Simply writing the code for a function is not enough to make it
+available to the Lisp reader. You have to, during module
initialization, let the Lisp reader know about the new function. This
is done by calling `DEFSUBR' with the name of the function. This is
the sole purpose of the initialization function `syms_of_module'.
\1f
File: emodules.info, Node: Defining Variables, Next: Index, Prev: Defining Functions, Up: Top
-Defining Variables
-******************
+5 Defining Variables
+********************
- Rarely will you write a module that only contains functions. It is
+Rarely will you write a module that only contains functions. It is
common to also provide variables which can be used to control the
-behaviour of the function, or store the results of the function being
+behavior of the function, or store the results of the function being
executed. The actual C variable types are the same for modules and
internal XEmacs primitives, and the declaration of the variables is
identical.
One _very_ important difference between XEmacs variables and module
variables is how you use pure space. Simply put, you *never* use pure
space in XEmacs modules. The pure space storage is of a limited size,
-and is initialized propperly during the dumping of XEmacs. Because
+and is initialized properly during the dumping of XEmacs. Because
variables are being added dynamically to an already running XEmacs when
you load a module, you cannot use pure space. Be warned: *do not use
pure space in modules. Repeat, do not use pure space in modules.*
Lisp_Object Vsample_string;
int sample_boolean;
-
+
void
vars_of_module()
{
DEFVAR_LISP ("sample-string", &Vsample_string /*
This is a sample string, declared in a module.
-
+
Nothing magical about it.
*/);
-
+
DEFVAR_BOOL("sample-boolean", &sample_boolean /*
*Sample user-settable boolean.
*/);
-
+
sample_boolean = 0;
Vsample_string = build_string("My string");
}
Index
*****
+\0\b[index\0\b]
* Menu:
-* annatomy: Annatomy of a Module.
-* compiler: Introduction.
-* compiling: Compile Mode.
-* config.h: Required Header File.
-* defining functions: Defining Functions.
-* defining objects: Defining Variables.
-* defining variables: Defining Variables.
-* DEFSUBR: Declaring Functions.
-* DEFUN: Using DEFUN.
-* DEFVAR_BOOL: Defining Variables.
-* DEFVAR_INT: Defining Variables.
-* DEFVAR_LISP: Defining Variables.
-* dependancies: Loading other Modules.
-* DLL: Introduction.
-* docs_of_module: Required Functions.
-* documentation <1>: Initialization Mode.
-* documentation: Introduction.
-* DSO: Introduction.
+* anatomy: Anatomy of a Module. (line 6)
+* compiler: Introduction. (line 39)
+* compiling: Compile Mode. (line 6)
+* config.h: Required Header File. (line 6)
+* defining functions: Defining Functions. (line 6)
+* defining objects: Defining Variables. (line 6)
+* defining variables: Defining Variables. (line 6)
+* DEFSUBR: Declaring Functions. (line 6)
+* DEFUN: Using DEFUN. (line 6)
+* DEFVAR_BOOL: Defining Variables. (line 6)
+* DEFVAR_INT: Defining Variables. (line 6)
+* DEFVAR_LISP: Defining Variables. (line 6)
+* dependencies: Loading other Modules.
+ (line 6)
+* DLL: Introduction. (line 25)
+* docs_of_module: Required Functions. (line 47)
+* documentation <1>: Initialization Mode. (line 6)
+* documentation: Introduction. (line 69)
+* DSO: Introduction. (line 25)
* ELLCC: Environment Variables.
-* ellcc <1>: Using ellcc.
-* ellcc: Introduction.
+ (line 14)
+* ellcc <1>: Using ellcc. (line 6)
+* ellcc: Introduction. (line 39)
* ELLCFLAGS: Environment Variables.
+ (line 22)
* ELLDLLFLAGS: Environment Variables.
+ (line 32)
* ELLLD: Environment Variables.
+ (line 18)
* ELLLDFLAGS: Environment Variables.
+ (line 27)
* ELLMAKEDOC: Environment Variables.
+ (line 42)
* ELLPICFLAGS: Environment Variables.
-* Emacs Modules: Introduction.
-* emodules.h: Required Header File.
+ (line 36)
+* Emacs Modules: Introduction. (line 25)
+* emodules.h: Required Header File. (line 6)
* emodules_load: Loading other Modules.
+ (line 6)
* environment variables: Environment Variables.
-* format, module: Annatomy of a Module.
-* functions, declaring: Declaring Functions.
-* functions, defining: Using DEFUN.
-* functions, Lisp: Using DEFUN.
-* functions, required: Required Functions.
-* header files: Introduction.
-* help: Introduction.
-* include files: Required Header File.
-* initialization <1>: Initialization Mode.
-* initialization <2>: Required Variables.
-* initialization: Required Functions.
-* linker: Introduction.
-* linking: Link Mode.
-* module compiler: Using ellcc.
-* module format: Annatomy of a Module.
-* module skeleton: Annatomy of a Module.
+ (line 6)
+* format, module: Anatomy of a Module. (line 6)
+* functions, declaring: Declaring Functions. (line 6)
+* functions, defining: Using DEFUN. (line 6)
+* functions, Lisp: Using DEFUN. (line 6)
+* functions, required: Required Functions. (line 6)
+* header files: Introduction. (line 51)
+* help: Introduction. (line 69)
+* include files: Required Header File. (line 6)
+* initialization <1>: Initialization Mode. (line 6)
+* initialization <2>: Required Variables. (line 6)
+* initialization: Required Functions. (line 6)
+* linker: Introduction. (line 39)
+* linking: Link Mode. (line 6)
+* module compiler: Using ellcc. (line 6)
+* module format: Anatomy of a Module. (line 6)
+* module skeleton: Anatomy of a Module. (line 6)
* modules_of_module <1>: Loading other Modules.
-* modules_of_module: Required Functions.
-* objects, defining: Defining Variables.
-* objects, Lisp: Defining Variables.
-* paths: Other ellcc options.
-* required functions: Required Functions.
-* required header: Required Header File.
-* required variables: Required Variables.
-* samples: Introduction.
-* shared object: Introduction.
-* skeleton, module: Annatomy of a Module.
-* subrs: Using DEFUN.
-* syms_of_module: Required Functions.
-* variables, defining: Defining Variables.
-* variables, Lisp: Defining Variables.
-* variables, required: Required Variables.
-* vars_of_module: Required Functions.
+ (line 6)
+* modules_of_module: Required Functions. (line 40)
+* objects, defining: Defining Variables. (line 6)
+* objects, Lisp: Defining Variables. (line 6)
+* paths: Other ellcc options. (line 6)
+* required functions: Required Functions. (line 6)
+* required header: Required Header File. (line 6)
+* required variables: Required Variables. (line 6)
+* samples: Introduction. (line 61)
+* shared object: Introduction. (line 25)
+* skeleton, module: Anatomy of a Module. (line 6)
+* subrs: Using DEFUN. (line 6)
+* syms_of_module: Required Functions. (line 20)
+* variables, defining: Defining Variables. (line 6)
+* variables, Lisp: Defining Variables. (line 6)
+* variables, required: Required Variables. (line 6)
+* vars_of_module: Required Functions. (line 26)
\1f
Tag Table:
Node: Top\7f1536
-Node: Introduction\7f2884
-Node: Annatomy of a Module\7f7393
-Node: Required Header File\7f8209
-Node: Required Functions\7f10130
-Node: Required Variables\7f12379
-Node: Loading other Modules\7f15066
-Node: Using ellcc\7f17124
-Node: Compile Mode\7f18919
-Node: Initialization Mode\7f20287
-Node: Link Mode\7f25319
-Node: Other ellcc options\7f26466
-Node: Environment Variables\7f29046
-Node: Defining Functions\7f30737
-Node: Using DEFUN\7f32748
-Node: Declaring Functions\7f34459
-Node: Defining Variables\7f35802
-Node: Index\7f38047
+Node: Introduction\7f2883
+Node: Anatomy of a Module\7f7392
+Node: Required Header File\7f8207
+Node: Required Functions\7f10131
+Node: Required Variables\7f12860
+Node: Loading other Modules\7f15551
+Node: Using ellcc\7f18472
+Node: Compile Mode\7f20267
+Node: Initialization Mode\7f21635
+Node: Link Mode\7f26635
+Node: Other ellcc options\7f27785
+Node: Environment Variables\7f30369
+Node: Defining Functions\7f32066
+Node: Using DEFUN\7f34078
+Node: Declaring Functions\7f35779
+Node: Defining Variables\7f37127
+Node: Index\7f39351
\1f
End Tag Table
projects / chise / xemacs-chise.git.1 / blobdiff