|
693
|
1 @c -*-texinfo-*-
|
|
|
2 @c This is part of the XEmacs Lisp Reference Manual.
|
|
|
3 @c Copyright (C) 2001 Free Software Foundation, Inc.
|
|
|
4 @c See the file lispref.texi for copying conditions.
|
|
|
5
|
|
|
6 @setfilename ../../info/packaging.info
|
|
|
7
|
|
|
8 @c Macro to make formatting of the XEmacs pms name consistent.
|
|
|
9 @c Maybe @sc looks OK in HTML? If so, condition on Info.
|
|
|
10 @iftex
|
|
|
11 @macro xpms
|
|
|
12 XE@sc{macs} Packaging System
|
|
|
13 @end macro
|
|
|
14 @end iftex
|
|
|
15 @ifnottex
|
|
|
16 @macro xpms
|
|
|
17 XEmacs Packaging System
|
|
|
18 @end macro
|
|
|
19 @end ifnottex
|
|
|
20
|
|
|
21 @node Packaging, Lisp Data Types, Introduction, Top
|
|
|
22 @chapter The @xpms{}
|
|
|
23 @cindex package
|
|
|
24 @cindex packaging
|
|
|
25
|
|
|
26 The XEmacs distribution, starting with version 21, comes only with a
|
|
|
27 very basic set of built-in modes and libraries. Most of the libraries
|
|
|
28 that were part of the distribution of earlier versions of XEmacs are now
|
|
|
29 available separately. The user as well as the system administrator can
|
|
|
30 choose which packages to install; the actual installation process is
|
|
|
31 easy. This gives an installer the ability to tailor an XEmacs
|
|
|
32 installation for local needs with safe removal of unnecessary code.
|
|
|
33
|
|
|
34 This chapter describes how to package Lisp libraries for use with the
|
|
|
35 @xpms{}.
|
|
|
36
|
|
|
37 @emph{Please note carefully} that the term @dfn{package} as used in
|
|
|
38 XEmacs refers to an aggregation of Lisp code and/or data distributed as
|
|
|
39 a unit. It does not, as it does in many Lisps, refer to a way of
|
|
|
40 creating separate name spaces. XEmacs has no facility for providing
|
|
|
41 separate name spaces. (If we ever do get separate name spaces, we'll
|
|
|
42 probably regret overloading the nomenclature in this way, but it's
|
|
|
43 become established.)
|
|
|
44
|
|
|
45 @menu
|
|
|
46 Introduction:
|
|
|
47 * Package Overview:: Lisp Libraries and Packages.
|
|
|
48
|
|
|
49 Packaging Lisp Libraries:
|
|
|
50 * Package Terminology:: Basic stuff.
|
|
|
51 * Building Packages:: Turn packaged source into a tarball.
|
|
|
52 * Local.rules File:: Tell the @xpms{} about your host.
|
|
|
53 * Creating Packages:: Tell the @xpms{} about your package.
|
|
752
|
54 * Documenting Packages:: Explain your package to users and hackers.
|
|
693
|
55 @c * History:: History of the @xpms{}
|
|
|
56 @c * Installation:: Installing the @xpms{} with your (X)Emacs.
|
|
|
57 @c * Configuration:: Configuring the @xpms{} for use.
|
|
|
58 @c * Usage:: An overview of the operation of the @xpms{}.
|
|
|
59 @c * Bug Reports:: Reporting Bugs and Problems
|
|
|
60 @c * Frequently Asked Questions:: Questions and answers from the mailing list.
|
|
|
61
|
|
|
62 Internals and Package Release Engineering:
|
|
|
63 * Issues::
|
|
|
64 @end menu
|
|
|
65
|
|
|
66 @node Package Overview, Package Terminology, , Packaging
|
|
|
67 @chapter An overview of the @xpms{}
|
|
|
68
|
|
|
69 The @xpms{} is a system for administering the installation, upgrade, and
|
|
|
70 removal of Lisp libraries. For the end user, it provides facilities for
|
|
|
71 determining availability of packages and which versions at remote
|
|
|
72 sites. It will download and automatically install a package, ensuring
|
|
|
73 that any old files from previous versions of the package are removed
|
|
|
74 first. By providing a standard set of hierarchies for installation, it
|
|
|
75 makes configuration of XEmacs simpler. Furthermore, packages normally
|
|
|
76 provide ancillary auto-autoloads and custom-loads libraries, which are
|
|
|
77 automatically detected and loaded by XEmacs upon startup. This means
|
|
|
78 that once installed, all facilities of package, including autoloading
|
|
|
79 the library upon invocation of a command provided by the library and
|
|
|
80 convenient configuration and customization, are automatically available
|
|
|
81 to the user. There is no need to add autoloads or keybindings to in the
|
|
|
82 init file, and structured configuration of the package is available
|
|
|
83 through the Customize system even before the libraries are loaded.
|
|
|
84
|
|
|
85 All of this convenience comes at a cost. The cost of administration at
|
|
|
86 the package level is negligible compared to the benefits, of course.
|
|
|
87 However, the requirement that XEmacs find and load auto-autoloads and
|
|
|
88 custom-loads libraries comes at a fairly large cost in startup time. In
|
|
|
89 order to reduce this cost, XEmacs imposes fairly strict conditions on
|
|
|
90 the structure of an installed package.
|
|
|
91
|
|
|
92 Meeting these requirements, as well as simply providing the
|
|
|
93 auto-autoloads and the information about availability and so on does
|
|
|
94 impose some costs on the library maintainer. The @xpms{} also provides
|
|
|
95 structure and utilities to the library maintainer to make these tasks
|
|
|
96 easier. This manual documents the requirements and the tools that the
|
|
|
97 @xpms{} provides to ensure that a package satisfies them.
|
|
|
98
|
|
|
99 @menu
|
|
759
|
100 * The User View::
|
|
|
101 * The Library Maintainer View::
|
|
|
102 * The Package Release Engineer View::
|
|
693
|
103 @end menu
|
|
|
104
|
|
|
105
|
|
759
|
106 @node The User View, The Library Maintainer View, , Package Overview
|
|
|
107 @section The User View
|
|
693
|
108
|
|
|
109 @strong{N.B.} Much of the discussion in this section undoubtedly
|
|
|
110 belongs elsewhere, @ref{Packages,,,xemacs}.
|
|
|
111
|
|
|
112 From the user's point of view, an XEmacs binary package is simply a
|
|
|
113 standard tarball (usually gzipped) containing Lisp sources, compiled
|
|
|
114 Lisp, documentation, and possibly data files or supporting executables.
|
|
|
115 The tarball is unpacked using standard tools such as GNU tar and gzip.
|
|
|
116 The package system does impose certain requirements for automatic
|
|
|
117 configuration to work.
|
|
|
118
|
|
|
119 Here the main consideration is that the tarball ``expects'' to be
|
|
|
120 unpacked from the top of a package hierarchy. A @dfn{package hierarchy}
|
|
|
121 is basically an image of a classic Emacs ``run-in-place'' tree, with
|
|
|
122 @file{lisp}, @file{etc}, @file{info}, @file{man}, @file{lib-src}, and
|
|
|
123 @file{pkginfo} subdirectories of the top. The @file{pkginfo}
|
|
|
124 subdirectory is for use by the @xpms{} administration tools, and
|
|
|
125 currently contains a @file{MANIFEST.@var{package-name}} file for each
|
|
|
126 package to ensure that no cruft remains when a package is removed or
|
|
|
127 updated. The @file{lisp}, @file{etc}, and @file{lib-src} subdirectories
|
|
|
128 are further subdivided, with a subdirectory for each package. The
|
|
694
|
129 @file{info} directory obeys the usual conventions.
|
|
|
130 @emph{I.e.}, the @file{info} directory is flat
|
|
693
|
131 with a(n) (optional) @file{dir} file and one (set of) info file(s) per
|
|
694
|
132 package. The @file{man} subdirectory typically contains documentation
|
|
|
133 sources, separated by package. (It does not contain @file{man(1)}
|
|
|
134 pages, as Emacs provides very few of them.)
|
|
693
|
135
|
|
|
136 There are several standard package hierarchies, and administrators can
|
|
|
137 configure others at build time, while users can configure others at run
|
|
|
138 time. The standard system hierarchies are all subdirectories of an
|
|
|
139 @c #### This is possibly incorrect usage of "installation root."
|
|
|
140 XEmacs installation root, typically @file{/usr/local/lib/xemacs/}.
|
|
|
141 These are the @file{xemacs-packages}, @file{mule-packages},
|
|
|
142 @file{infodock-packages}, and @file{site-packages} hierarchies. Each
|
|
|
143 has the structure described above, but the purposes differ. The
|
|
|
144 @file{xemacs-packages} is the normal place for installing ``official''
|
|
|
145 packages and many third-party libraries. Unfortunately, it is not yet
|
|
|
146 quite possible to read libraries containing international characters
|
|
|
147 with a non-Mule XEmacs, so such libraries are sequestered in the
|
|
|
148 @file{mule-packages} hierarchy. Some packages are compatible only with
|
|
|
149 the Infodock development environment, and they will be installed in the
|
|
|
150 @file{infodock-packages} hierarchy. The @file{site-packages} hierarchy
|
|
|
151 is for packages not distributed by XEmacs.org, typically locally
|
|
|
152 developed.
|
|
|
153
|
|
|
154 Packages are in principle supposed to be XEmacs version-independent, but
|
|
|
155 if such dependencies are unavoidable, additional standard package
|
|
|
156 hierarchies may be installed under version directories, @emph{e.g.}
|
|
|
157 @file{/usr/local/lib/xemacs-21.4.6/}.
|
|
|
158
|
|
|
159 Users who do not have sufficient privilege to install packages in the
|
|
|
160 system hierarchies may install package hierarchies under
|
|
|
161 @file{~/.xemacs}. At present only the @file{xemacs-packages} and
|
|
|
162 @file{mule-packages} hierarchies are supported, but it might make sense
|
|
|
163 to extend this to support @file{infodock-packages} and
|
|
|
164 @file{site-packages} hierarchies in the future.
|
|
|
165
|
|
|
166 The package hierarchies are not searched directly for libraries to be
|
|
|
167 loaded; this would be very costly. Instead, the hierarchies are ordered
|
|
|
168 according to certain rules, and searched for package lisp directories at
|
|
|
169 invocation. These directories are added to the general
|
|
|
170 @code{load-path}. As usual, it is @code{load-path} that is searched at
|
|
|
171 run-time. This approach is somewhat costly at initialization, but
|
|
|
172 results in a very ``clean'' @code{load-path}.
|
|
|
173
|
|
|
174 The order of search can be changed at build time by specifying the
|
|
|
175 @samp{--package-path} option to @file{configure}, or at run-time by
|
|
|
176 specifying the @code{EMACSPACKAGEPATH} environment variable.
|
|
|
177 @xref{Packages,,,xemacs}.
|
|
|
178
|
|
|
179 @c #### The following description is quite possibly inaccurate.
|
|
694
|
180 @c Please, Michael, write some specs up!
|
|
693
|
181 The default order of search is hierarchically determined. First, the
|
|
|
182 roots are ordered. The @dfn{early} roots are the user-specific roots,
|
|
|
183 typically @file{~/.xemacs}. The @dfn{late} roots are the system roots,
|
|
|
184 typically @file{/usr/local/lib/xemacs-21.4.6} and
|
|
|
185 @file{/usr/local/lib/xemacs}, in that order. All hierarchies for a
|
|
|
186 given root are searched for package Lisp directories, which are appended
|
|
|
187 to @code{load-path} in the order found. Then the search proceeds to the
|
|
|
188 next root, whose results will be appended to the @code{load-path}
|
|
|
189 generated by previous roots.
|
|
|
190
|
|
|
191 Second, the hierarchies below each root are searched in the order
|
|
|
192 @file{site-packages}, @file{infodock-packages}, @file{mule-packages},
|
|
|
193 then @file{xemacs-packages}.
|
|
|
194
|
|
|
195 In each hierarchy there should be a @file{lisp} subdirectory, containing
|
|
|
196 directories named for the packages. Each package's Lisp libraries thus
|
|
|
197 are contained in a directory of the form
|
|
|
198 @var{root}/@var{hierarchy}/lisp/@var{package}/.
|
|
|
199
|
|
|
200 With such a complex search algorithm, the possibility of libraries being
|
|
|
201 shadowed by another library with the same name is quite real. There are
|
|
|
202 two considerations here. First, every XEmacs package contains certain
|
|
|
203 libraries with constant names. These are
|
|
|
204
|
|
|
205 @table @file
|
|
|
206 @item _pkg.el
|
|
|
207 Lisp code to inform the package administration system about the package
|
|
|
208
|
|
|
209 @item auto-autoloads.el
|
|
|
210 Lisp code to set up autoloaded functions and variables that may be
|
|
|
211 needed at load time
|
|
|
212
|
|
|
213 @item custom-load.el
|
|
|
214 definitions of configuration variables for use with the Customize
|
|
|
215 system.
|
|
|
216 @end table
|
|
|
217
|
|
|
218 They are special-cased, because the way they are used prevents shadowing
|
|
|
219 from being an issue.
|
|
|
220
|
|
|
221 Second, it is possible that multiple copies of some library, or
|
|
|
222 different libraries with the same name, are installed in various places
|
|
|
223 in the hierarchies. To detect such shadows, use
|
|
|
224 @code{list-load-path-shadows}.
|
|
|
225
|
|
|
226 Finally, note that most basic Emacs functionality, including most of the
|
|
|
227 Lisp API, is implemented in Lisp libraries. Because they use internal
|
|
|
228 reserved APIs that are subject to change according the needs of the
|
|
|
229 developers, these libraries are distributed with the XEmacs binary, and
|
|
|
230 are called @dfn{core Lisp libraries}. Most core Lisp libraries are
|
|
|
231 ``preloaded'' into the Emacs binary and in normal usage are never
|
|
|
232 explicitly loaded. However, they can be explicitly loaded, and if so
|
|
|
233 they are searched on @code{load-path}.
|
|
|
234 @c #### Is this correct? It is not for C-h f, for example.
|
|
|
235 Furthermore, functions such as @code{locate-library} will also search on
|
|
|
236 the @code{load-path}. The searching takes place under somewhat
|
|
|
237 different rules from those used for packaged Lisp. It is probably
|
|
|
238 easiest to think of the package hierarchy searching algorithm as
|
|
|
239 receiving a @code{load-path} initialized to the core Lisp directories.
|
|
|
240
|
|
|
241
|
|
759
|
242 @node The Library Maintainer View, The Package Release Engineer View, The User View, Package Overview
|
|
|
243 @section The Library Maintainer View
|
|
693
|
244
|
|
|
245 From the library maintainer's viewpoint, the advantages to the @xpms{}
|
|
|
246 stem from the convenience to the user of installation and upgrade.
|
|
|
247 Since an installed package automatically registers its entry points via
|
|
|
248 autoload and its configuration variables with the Customize system,
|
|
|
249 configuration FAQs are reduced. When it's easy to upgrade, users learn
|
|
|
250 to try @samp{Tools | Packages | Update Installed Packages} before
|
|
|
251 posting a FAQ whose answer is ``long since fixed, please upgrade.''
|
|
|
252
|
|
|
253 This comes at some cost, as the library maintainer needs to arrange that
|
|
|
254 the package be installed in a directory structure that satisfies the
|
|
|
255 requirements of the @xpms{}. Autoload cookies and defcustoms must also
|
|
|
256 be added to existing libraries. The @xpms{} provides infrastructure to
|
|
|
257 assure that all of these annoyances need only be dealt with once. The
|
|
|
258 autoload cookies and defcustoms are beyond the scope of this chapter, but
|
|
|
259 most maintainers of modern packages are already familiar with these
|
|
|
260 mechanisms.
|
|
|
261
|
|
|
262 The @xpms{} may be divided into the @dfn{infrastructure} common to all
|
|
|
263 packages, and the package-specific @dfn{control files}. The
|
|
|
264 infrastructure supports global builds, installation, and generation of
|
|
|
265 the ``sumo'' bundles of packages, as well as generation of individual
|
|
|
266 packages. The package control files describe the structure of the
|
|
|
267 package's source tree and provide administrative information.
|
|
|
268
|
|
|
269 @menu
|
|
|
270 * Infrastructure:: Global Makefiles and common rules.
|
|
|
271 * Control Files:: Package-specific Makefiles and administrative files.
|
|
|
272 * Obtaining:: Obtaining the @xpms{} and required utilities.
|
|
|
273 @end menu
|
|
|
274
|
|
759
|
275 @node Infrastructure, Control Files, , The Library Maintainer View
|
|
693
|
276 @subsection Infrastructure
|
|
|
277
|
|
|
278 In order to get the greatest benefit from the @xpms{}, a library
|
|
|
279 maintainer should place the package sources in an appropriate place in
|
|
|
280 the XEmacs source package hierarchy, and arrange to have the source
|
|
|
281 package imported into the XEmacs CVS repository.
|
|
|
282 @c #### the parenthetical remark should go to "issues."
|
|
|
283 (We realize that the
|
|
|
284 latter requirement can be quite burdensome. We are working on ways to
|
|
|
285 remove this requirement, but for the present it remains necessary.) The
|
|
|
286 library maintainer must also keep sources for any packages his/her
|
|
|
287 package requires. This requirement is somewhat burdensome, but unlikely
|
|
|
288 to be relaxed because of the implementation of compilation of macros in
|
|
|
289 Emacs Lisp. Macros cannot be called by compiled Lisp (the macro
|
|
|
290 expansion, which is always known at compile time, is inlined), so the
|
|
|
291 source of the macro must be loaded before compiling the called function.
|
|
|
292
|
|
|
293 The source package hierarchy may be rooted anywhere. The CVS module is
|
|
|
294 called ``packages,'' so we will refer to the top directory of the source
|
|
|
295 package hierarchy as ``the @file{packages} directory.'' The
|
|
|
296 @file{packages} directory contains two source subdirectories,
|
|
|
297 @file{xemacs-packages} and @file{mule-packages} (for convenience in
|
|
|
298 segregating the packages which depend on Mule, as they will cause
|
|
|
299 load-time errors in a non-Mule XEmacs). Each subdirectory contains many
|
|
|
300 package source directories, whose internal structure is not specified.
|
|
|
301 That structure is left up to the convenience of the library maintainers.
|
|
|
302 The requirements on the top directory of an individual package source
|
|
|
303 tree are given below, @ref{Control Files}.
|
|
|
304
|
|
|
305 The @file{packages} directory contains some auxiliary Lisp libraries
|
|
|
306 used in the compilation and packaging process. The content of these
|
|
761
|
307 libraries is of interest primarily to the packaging engineers, @ref{The
|
|
|
308 Package Release Engineer View}.
|
|
693
|
309
|
|
|
310 Finally, the @file{packages}, @file{packages/xemacs-packages}, and
|
|
|
311 @file{packages/mule-packages} directories contain @file{Makefile}s and
|
|
|
312 include files to control the package creation process. The
|
|
|
313 @file{Makefile}s in @file{packages/xemacs-packages} and
|
|
|
314 @file{packages/mule-packages} simply define the default sets of known
|
|
|
315 packages and include @file{../iterate.rules}, which implements recursive
|
|
|
316 building of all target packages.
|
|
|
317
|
|
|
318 The @samp{make} infrastructure in @file{packages} includes
|
|
|
319
|
|
|
320 @table @file
|
|
|
321 @item Makefile
|
|
|
322 controls building of individual packages, local installation, and
|
|
|
323 bundling of ``sumo'' tarballs
|
|
|
324
|
|
|
325 @item iterate.rules
|
|
|
326 controls recursive builds of multiple packages
|
|
|
327
|
|
|
328 @item XEmacs.rules
|
|
|
329 provides the rules for building and packaging. Included by all package
|
|
|
330 @file{Makefile}s.
|
|
|
331
|
|
|
332 @item Local.rules
|
|
|
333 provides local configuration, such as installation targets and staging
|
|
|
334 directories, as well as a number of kludges (many now obsolete) required
|
|
|
335 for building packages on the Windows platform.
|
|
|
336
|
|
|
337 @item Local.rules.template
|
|
|
338 a template for Local.rules, liberally commented
|
|
|
339
|
|
|
340 @item Local.rules.mk
|
|
|
341 consistency checking for @file{Local.rules}, included by both the
|
|
|
342 top-level @file{Makefile} and by @file{XEmacs.rules}.
|
|
|
343
|
|
|
344 @c #### Add to "issues"
|
|
|
345 @item package-compile.el
|
|
|
346 compile environment (@emph{e.g.}, load-path) setup. It is very bogus
|
|
|
347 that this is here, an alternative mechanism is likely to be provided.
|
|
|
348 @end table
|
|
|
349
|
|
|
350 Of these, only @file{Local.rules} and @file{package-compile.el} need to
|
|
|
351 be modified by the library maintainer. The changes to Local.rules
|
|
|
352 affect only your environment. This should need to be done only once
|
|
|
353 when first preparing the source environment. The necessary
|
|
|
354 modifications to @file{package-compile.el} need to be done for each
|
|
|
355 package and are discussed in the next section, @ref{Control Files}.
|
|
|
356
|
|
|
357
|
|
759
|
358 @node Control Files, Obtaining, Infrastructure, The Library Maintainer View
|
|
693
|
359 @subsection Control Files
|
|
|
360
|
|
|
361 Each package source must contain a number of control files in the
|
|
|
362 top-level directory. These files in general can be created and then
|
|
|
363 ignored, except for a few variables that need to be updated when new
|
|
|
364 versions are released. In most cases even adding, renaming, and
|
|
|
365 removing library source files can be handled by generic rules.
|
|
|
366
|
|
|
367 The package control files include
|
|
|
368
|
|
|
369 @table @file
|
|
|
370 @item Makefile
|
|
|
371 Must set a few @file{make} variables used by the administrative
|
|
|
372 utilities, and defines a couple of package-building targets to depend on
|
|
|
373 appropriate targets defined generically in @file{XEmacs.rules}. It may
|
|
|
374 also provide various variables and rules to transform the source tree
|
|
|
375 structure into that expected by the run-time system.
|
|
|
376
|
|
|
377 @item package-info.in
|
|
|
378 Provides a template for package information to be provided to the
|
|
|
379 administrative utilities. Static variables that are rarely changed
|
|
|
380 (such as the package's name) are entered as literals. Some variables
|
|
|
381 are generated by the build process (build dates and MD5 checksums) and
|
|
|
382 are automatically filled in. Finally, some variables that change
|
|
|
383 irregularly (dependences and even version numbers) are set as
|
|
|
384 @file{make} variables in the @file{Makefile}.
|
|
|
385
|
|
|
386 @item ChangeLog
|
|
|
387 Not strictly required, but normally a ChangeLog will be added by the
|
|
|
388 XEmacs package maintainer if different from the upstream maintainer.
|
|
|
389
|
|
|
390 @item package-compile.el
|
|
|
391 compile environment (@emph{e.g.}, load-path) setup. It is very bogus
|
|
|
392 that this is here, an alternative mechanism is likely to be provided.
|
|
|
393
|
|
|
394 @item _pkg.el
|
|
|
395 Generated. Simply does a @code{package-provide} for the package.
|
|
|
396
|
|
|
397 @item _auto-autoloads.el
|
|
|
398 Generated. Read when XEmacs is initialized, and provides autoloads for
|
|
|
399 all defuns and other specially-marked forms in the sources.
|
|
|
400
|
|
|
401 @item custom-loads.el
|
|
|
402 Generated. Read when XEmacs is initialized, and informs the Customize
|
|
|
403 subsystem how to find the defcustom forms needed to create Customization
|
|
|
404 forms for the usre configuration variables of the package.
|
|
|
405 @end table
|
|
|
406
|
|
|
407
|
|
759
|
408 @node Obtaining, , Control Files, The Library Maintainer View
|
|
693
|
409 @subsection Obtaining the @xpms{} and Required Utilities
|
|
|
410
|
|
|
411 Currently both the infrastructure for creating XEmacs packages and the
|
|
|
412 package sources themselves are available only by CVS. See
|
|
|
413 @uref{http://www.xemacs.org/Develop/cvsaccess.html} for more
|
|
|
414 intformation.
|
|
|
415
|
|
|
416 The @xpms{} currently requires GNU @file{make}, and probably XEmacs, to
|
|
|
417 build packages.
|
|
|
418
|
|
|
419
|
|
759
|
420 @node The Package Release Engineer View, , The Library Maintainer View, Package Overview
|
|
|
421 @subsection The Package Release Engineer View
|
|
693
|
422
|
|
694
|
423 The XEmacs Package Release Engineer is responsible for keeping the
|
|
|
424 system coherent. The changes to @file{packages/package-compile.el} and
|
|
|
425 @file{packages/xemacs-packages/Makefile} required to make the package
|
|
|
426 available to others, and for building SUMO tarballs, @emph{etc}, are
|
|
|
427 done by the Package Release Engineer, not individual library
|
|
|
428 maintainers.
|
|
693
|
429
|
|
694
|
430 The Package Release Engineer also maintains assorted infrastructure for
|
|
|
431 actually making releases. These are generally available for inspection
|
|
|
432 in the @code{xemacs-builds} module in the CVS repository.
|
|
|
433
|
|
|
434 @c #### To be completed.
|
|
693
|
435
|
|
|
436
|
|
|
437 @c #### The following section is lifted verbatim from the XEmacs User's
|
|
|
438 @c Manual, file packages.texi.
|
|
|
439 @node Package Terminology, Building Packages, Package Overview, Packaging
|
|
|
440 @comment node-name, next, previous, up
|
|
|
441 @heading Package Terminology:
|
|
|
442
|
|
|
443 @subsection Libraries and Packages
|
|
|
444 @cindex library
|
|
|
445 @cindex package
|
|
|
446
|
|
|
447 A Lisp @dfn{library} is a single loadable file containing Lisp code. It
|
|
|
448 may be in source or byte-compiled form. A Lisp @dfn{package} is a set
|
|
|
449 of one or more libraries, usually related to each other in some way,
|
|
|
450 bundled with administrative information for convenient distribution.
|
|
|
451
|
|
|
452 @subsection Package Flavors
|
|
|
453
|
|
|
454 There are two main flavors of packages.
|
|
|
455
|
|
|
456 @table @strong
|
|
|
457 @item Regular Packages
|
|
|
458 @cindex regular package
|
|
|
459 A regular package is a set of Lisp libraries design to cooperate with
|
|
|
460 one another. A very complex example is Gnus. One may not in general
|
|
|
461 safely remove any of the component libraries.
|
|
|
462
|
|
|
463 @item Single-File Packages
|
|
|
464 @cindex single-file package
|
|
901
|
465 A single-file package is a collection of thematically related but
|
|
693
|
466 otherwise independent Lisp libraries. These libraries are bundled
|
|
|
467 together for convenience of the maintainers. Usually individual
|
|
|
468 libraries may be deleted at will without any loss of functionality of
|
|
|
469 other libraries in the package. However, we would recommend that you
|
|
|
470 follow this rule of thumb: "When in doubt, don't delete". If it's
|
|
|
471 really that big a deal, request that the maintainers split the package
|
|
|
472 into smaller aggregations.
|
|
|
473 @end table
|
|
|
474
|
|
|
475 @subsection Package Distributions
|
|
|
476 @cindex package distributions
|
|
|
477 @cindex binary packages
|
|
|
478 @cindex source packages
|
|
|
479 XEmacs Lisp packages are distributed in two ways. @dfn{Binary packages}
|
|
|
480 are used by system administrators and end users. They are packaged in a
|
|
|
481 form convenient for direct installation into an XEmacs package
|
|
|
482 hierarchy. @dfn{Source packages} are for developers and include all
|
|
|
483 files necessary for rebuilding byte-compiled lisp and creating tarballs
|
|
|
484 for distribution or installation. This is all of the package author's
|
|
|
485 source code plus all of the files necessary to build distribution
|
|
|
486 tarballs (Unix Tar format files, gzipped for space savings).
|
|
|
487 @c #### This next is an Evile Practice and should be discontinued.
|
|
|
488 (Occasionally sources that are not relevant to XEmacs are removed.)
|
|
|
489
|
|
|
490 Currently, source packages are only available via CVS. See
|
|
|
491 @url{http://www.xemacs.org/Develop/cvsaccess.html} for details.
|
|
|
492
|
|
|
493 The package distributions are also split according to major features
|
|
|
494 required in XEmacs to support them. At present there are @dfn{generic}
|
|
|
495 packages, which can be loaded by @emph{any} XEmacs, and @dfn{Mule}
|
|
|
496 packages, which @emph{require} Mule support or they will cause errors
|
|
|
497 when loaded. Note that there is no guarantee that a generic package
|
|
|
498 will have any useful functionality in a minimally configured XEmacs. As
|
|
|
499 long as any XEmacs can successfully load the package's libraries
|
|
|
500 (perhaps given other required Lisp libraries), it will be classified as
|
|
|
501 generic. At the present time only Mule packages need be treated
|
|
|
502 specially, and even those only if they contain multibyte characters.
|
|
|
503
|
|
|
504
|
|
|
505 @c #### The following section is lifted verbatim from the XEmacs User's
|
|
|
506 @c Manual, file packages.texi.
|
|
|
507 @node Building Packages, Local.rules File, Package Terminology, Packaging
|
|
|
508 @comment node-name, next, previous, up
|
|
|
509 @cindex building packages
|
|
|
510 @cindex package building
|
|
|
511 @heading Building Packages:
|
|
|
512 Currently, source packages are only available via anonymous CVS. See
|
|
|
513 @url{http://www.xemacs.org/Develop/cvsaccess.html} for details of
|
|
|
514 checking out the @file{packages} module.
|
|
|
515
|
|
|
516 @subsection Prerequisites for Building Source Packages
|
|
|
517
|
|
|
518 @table @code
|
|
|
519 @item GNU cp
|
|
|
520 @item GNU install
|
|
|
521 (or a BSD compatible install program).
|
|
|
522 @item GNU make
|
|
|
523 (3.75 or later preferred).
|
|
|
524 @item makeinfo
|
|
|
525 (1.68 from texinfo-3.11 or later required, 1.69 from Texinfo 4 preferred).
|
|
|
526 @item GNU tar
|
|
|
527 (or equivalent).
|
|
|
528 @item GNU gzip
|
|
|
529 (or equivalent).
|
|
|
530 @item A properly configured @file{Local.rules} file.
|
|
|
531 @ref{Local.rules File}.
|
|
|
532 @end table
|
|
|
533
|
|
|
534 And of course, XEmacs, 21.0 or higher.
|
|
|
535
|
|
|
536 @subsection What You Can Do With Source Packages
|
|
|
537
|
|
|
538 The packages CVS sources are most useful for creating XEmacs package
|
|
|
539 tarballs for installation into your own XEmacs installations or for
|
|
|
540 distributing to others.
|
|
|
541
|
|
|
542 The supported @file{make} targets are:
|
|
|
543
|
|
|
544 @table @code
|
|
|
545 @item all
|
|
|
546 Bytecompile all files, build and bytecompile byproduct files like
|
|
|
547 @file{auto-autoloads.el} and @file{custom-load.el}. Create info version
|
|
|
548 of TeXinfo documentation if present.
|
|
|
549
|
|
|
550 @c #### Why do we need this _and_ the binkit target?
|
|
|
551 @item bindist
|
|
|
552 Does a @code{make all} as well as create a binary package tarball in the
|
|
|
553 staging directory.
|
|
|
554
|
|
|
555 @item install
|
|
|
556 Bytecompile all files, build and bytecompile byproduct files like
|
|
|
557 @file{auto-autoloads.el} and @file{custom-load.el}. Create info version
|
|
|
558 of TeXinfo documentation if present. And install everything into the
|
|
|
559 staging directory.
|
|
|
560
|
|
|
561 @item srckit
|
|
|
562 Usually simply depends on @code{srckit-std}, with no actions. This does
|
|
|
563 a @code{make distclean} and creates a package source tarball in the
|
|
|
564 staging directory. This is generally only of use for package
|
|
|
565 maintainers.
|
|
|
566
|
|
|
567 @item binkit
|
|
|
568 May depend on @code{binkit-sourceonly}, @code{binkit-sourceinfo},
|
|
|
569 @code{binkit-sourcedata}, or @code{binkit-sourcedatainfo}, with no
|
|
|
570 actions. @code{sourceonly} indicates there is nothing to install in a
|
|
|
571 data directory or info directory. @code{sourceinfo} indicates that
|
|
|
572 source and info files are to be installed. @code{sourcedata} indicates
|
|
|
573 that source and etc (data) files are to be installed.
|
|
|
574 @code{sourcedatainfo} indicates source, etc (data), and info files are
|
|
|
575 to be installed. A few packages have needs beyond the basic templates
|
|
|
576 so this is not yet complete.
|
|
|
577
|
|
|
578 @item dist
|
|
|
579 Runs the rules @code{srckit} followed by @code{binkit}. This is
|
|
|
580 primarily of use by XEmacs maintainers producing files for distribution.
|
|
|
581
|
|
|
582 @item clean
|
|
|
583 Remove all built files except @file{auto-autoloads.el} and
|
|
|
584 @file{custom-load.el}.
|
|
|
585
|
|
|
586 @item distclean
|
|
|
587 Remove all created files.
|
|
|
588 @end table
|
|
|
589
|
|
|
590 @c #### The following section is lifted verbatim from the XEmacs User's
|
|
|
591 @c Manual, file packages.texi.
|
|
|
592 @node Local.rules File, Creating Packages, Building Packages, Packaging
|
|
|
593 @comment node-name, next, previous, up
|
|
|
594 @cindex local.rules
|
|
|
595 @heading The Local.rules File:
|
|
|
596 This file in @file{packages} provides the @xpms{} with information about
|
|
|
597 the local configuration and environment. To create @file{Local.rules},
|
|
|
598 simply copy @file{Local.rules.template} from that directory to
|
|
|
599 @file{Local.rules} and edit it to suit your needs.
|
|
|
600
|
|
|
601 These are the variables in @file{Local.rules} that you will need to
|
|
|
602 provide values for. The following variables control which packages will
|
|
|
603 be built:
|
|
|
604
|
|
|
605 @table @var
|
|
|
606 @item XEMACS_PACKAGES
|
|
|
607 The default is @samp{xemacs-packages}, which results in the set in
|
|
|
608 the @file{xemacs-packages/Makefile} @code{PACKAGES} variable.
|
|
|
609
|
|
|
610 Otherwise, it should be a list of package source directories prefixed by
|
|
|
611 @samp{xemacs-packages}:
|
|
|
612
|
|
|
613 @example
|
|
|
614 XEMACS_PACKAGES = xemacs-packages/xemacs-base xemacs-packages/bbdb
|
|
|
615 @end example
|
|
|
616
|
|
|
617 @item BUILD_WITHOUT_MULE
|
|
|
618 The default is the empty value.
|
|
|
619
|
|
|
620 Building from CVS defaults to building the Mule
|
|
|
621 packages. Set this to 't' if you don't want/have Mule.
|
|
|
622
|
|
|
623 @item MULE_PACKAGES
|
|
|
624 The default is @samp{mule-packages}, which results in the set in
|
|
|
625 the @file{mule-packages/Makefile} @code{PACKAGES} variable.
|
|
|
626
|
|
|
627 Otherwise, it should be a list of package source directories prefixed by
|
|
|
628 @samp{mule-packages}:
|
|
|
629
|
|
|
630 @example
|
|
|
631 MULE_PACKAGES = mule-packages/mule-base mule-packages/skk
|
|
|
632 @end example
|
|
|
633
|
|
|
634 @item PACKAGE_INDEX
|
|
|
635 The default is @file{package-index}.
|
|
|
636
|
|
|
637 If you want the package index file to have a different name, change
|
|
|
638 this. This is probably a bad idea unless you are a packages release
|
|
|
639 engineer, as it will confuse the package administration tools.
|
|
|
640 @end table
|
|
|
641
|
|
|
642 The following variables determine where files are installed and how they
|
|
|
643 are installed. Several of the defaults use the variable
|
|
|
644 @var{XEMACS_PACKAGES_BASE}. Never set this variable in
|
|
|
645 @file{Local.rules}; it is automatically set in @file{XEmacs.rules}.
|
|
|
646
|
|
|
647 @table @asis
|
|
|
648 @item @var{XEMACS_STAGING}
|
|
|
649 The default is @file{$@{XEMACS_PACKAGES_BASE@}/../xemacs-packages}.
|
|
|
650
|
|
|
651 Generic packages will be installed here. This can be the final
|
|
|
652 destination for files or symlinks (if the packages are being installed
|
|
|
653 locally), or a clean staging area for building tarballs.
|
|
|
654
|
|
|
655 @strong{N.B.} @samp{make bindist} ignores this variable. It should be
|
|
|
656 handled by the administration utilities, but currently isn't.
|
|
|
657
|
|
|
658 @item @var{MULE_STAGING}
|
|
|
659
|
|
|
660 The default is @file{$@{XEMACS_PACKAGES_BASE@}/../mule-packages}.
|
|
|
661
|
|
|
662 Packages requiring Mule to load correctly will be installed here. This
|
|
|
663 can be the final destination for files or symlinks (if the packages are
|
|
|
664 being installed locally), or a clean staging area for building tarballs.
|
|
|
665
|
|
|
666 @strong{N.B.} @samp{make bindist} ignores this variable. It should be
|
|
|
667 handled by the administration utilities, but currently isn't.
|
|
|
668
|
|
|
669 @item symlink
|
|
|
670 The default is the empty value.
|
|
|
671
|
|
|
672 Set this to 't' if you want to simulate ``running in place.'' It is
|
|
|
673 currently not possible to ask XEmacs to use any package source tree as
|
|
|
674 an automatically configured member of @code{load-path}, and it is
|
|
|
675 unlikely that complex trees such as that of the Gnus package will ever
|
|
|
676 be able to ``run in place.'' This variable, when set to `t', causes the
|
|
|
677 build process to create a symlink farm otherwise identical to an
|
|
|
678 installed tree of binary packages. Thus it is purely a space
|
|
|
679 optimization.
|
|
|
680
|
|
|
681 Setting this is incompatible with @samp{make bindist}.
|
|
|
682 @end table
|
|
|
683
|
|
|
684 The following variables determine how packages are made.
|
|
|
685
|
|
|
686 @table @var
|
|
|
687 @item XEMACS
|
|
|
688 The default is @samp{xemacs}.
|
|
|
689
|
|
|
690 The path to the XEmacs executable you wish to use to compile the
|
|
|
691 packages and execute Lisp build scripts.
|
|
|
692
|
|
|
693 @item XEMACS_NATIVE_NT
|
|
|
694 The default is the empty value.
|
|
|
695
|
|
|
696 Set this to 't' if you are building on WinNT. It controls hairy shell
|
|
|
697 quoting in the @file{Makefile}s.
|
|
|
698
|
|
|
699 @item INSTALL
|
|
|
700 The default is @samp{install -c}.
|
|
|
701
|
|
|
702 The path to your BSD compatible install program.
|
|
|
703
|
|
|
704 @item TAR
|
|
|
705 The default is @samp{tar}.
|
|
|
706
|
|
|
707 The path to your tar program.
|
|
|
708
|
|
|
709 @item BZIP2
|
|
|
710 The default is the empty value.
|
|
|
711
|
|
|
712 If unset, bzipped tarballs will not be built. If this is set to
|
|
|
713 something that resolves to a @samp{bzip2} executable, bzip2 tarballs
|
|
|
714 will be built @emph{in addition to} @samp{gzip} tarballs.
|
|
|
715
|
|
|
716 @item MAKEINFO
|
|
|
717 The default is @samp{makeinfo}.
|
|
|
718
|
|
|
719 The path to your @file{makeinfo} program
|
|
|
720 @end table
|
|
|
721
|
|
|
722
|
|
|
723 @c #### The following section is lifted verbatim from the XEmacs User's
|
|
|
724 @c Manual, file packages.texi.
|
|
752
|
725 @node Creating Packages, Documenting Packages, Local.rules File, Packaging
|
|
693
|
726 @comment node-name, next, previous, up
|
|
|
727 @cindex creating packages
|
|
|
728 @heading Creating Packages:
|
|
|
729 Creating a package from an existing Lisp library is not very difficult.
|
|
|
730
|
|
|
731 In addition to the Lisp libraries themselves, you need a
|
|
|
732 @file{package-info.in} file and a simple @file{Makefile}. The rest is
|
|
|
733 done by @file{XEmacs.rules}, part of the packaging system
|
|
|
734 infrastructure.
|
|
|
735
|
|
|
736 @file{package-info.in} contains a single Lisp form like this:
|
|
|
737
|
|
|
738 @example
|
|
|
739 (NAME ; your package's name
|
|
|
740 (standards-version 1.1
|
|
|
741 version VERSION ; Makefile
|
|
|
742 author-version AUTHOR_VERSION ; Makefile
|
|
|
743 date DATE ; Makefile
|
|
|
744 build-date BUILD_DATE ; generated
|
|
|
745 maintainer MAINTAINER ; Makefile
|
|
|
746 distribution DISTRIBUTION ; "mule" if MULE is needed,
|
|
|
747 ; else "xemacs"
|
|
|
748 priority high
|
|
|
749 category CATEGORY ; Makefile
|
|
|
750 dump nil
|
|
|
751 description "description" ; a one-line description string
|
|
|
752 filename FILENAME ; obsolete
|
|
|
753 md5sum MD5SUM ; generated
|
|
|
754 size SIZE ; generated
|
|
|
755 provides (FEATURE ...) ; one for every `provides' form
|
|
|
756 requires (REQUIRES) ; Makefile
|
|
|
757 ; NOT run-time dependencies! These
|
|
|
758 ; are files that provide macros or
|
|
|
759 ; defsubsts that must be inlined.
|
|
|
760 type regular
|
|
|
761 ))
|
|
|
762 @end example
|
|
|
763
|
|
|
764 You should replace NAME, DISTRIBUTION, DESCRIPTION, and FEATURE ... with
|
|
|
765 appropriate values, according to the comments. Fields marked as
|
|
|
766 @samp{obsolete} can be ignored. Fields marked as @samp{generated} are
|
|
|
767 generated by the package construction process, and will be filled in
|
|
|
768 automatically. Fields marked as @samp{Makefile} should be set as
|
|
|
769 variables in the @file{Makefile}.
|
|
|
770
|
|
|
771 The @samp{provides} can be done automatically, but currently aren't. It
|
|
|
772 would probably be a good idea to set them in the @file{Makefile} (they
|
|
|
773 do change, fairly often, but at present they aren't.
|
|
|
774
|
|
749
|
775 @c #### This organization sucks. Should break up by component, with
|
|
|
776 @c theory of operations, example, and reference subsections.
|
|
693
|
777 The @file{Makefile} is quite stylized. The idea is similar to an
|
|
|
778 @file{Imakefile} or an @code{automake} file: the complexity is hidden in
|
|
|
779 generic rules files, in this case the @file{XEmacs.rules} include file
|
|
|
780 in the top directory of the packages hierarchy.
|
|
|
781
|
|
749
|
782 It is important to note that the XEmacs used to compile packages is the
|
|
|
783 bare minimum: it is called with the @samp{-no-user-file -no-site-file
|
|
|
784 -no-autoloads}. This means that anything not dumped into XEmacs by
|
|
|
785 default needs to be specified in the @samp{REQUIRES} variable (for
|
|
|
786 packaged Lisp) or in some cases the @samp{PRELOADS} (autoloads used in
|
|
|
787 libraries mentioned in @samp{PRELOADS}).
|
|
|
788
|
|
693
|
789 An @xpms{} @file{Makefile} has three components. First, there is a
|
|
|
790 variable definition section. The standard @xpms{} @file{make} variables
|
|
|
791 must be defined here for use by the @file{XEmacs.rules} include file.
|
|
|
792 Second, the file @file{../../XEmacs.rules} is included. Finally, the
|
|
|
793 @file{make} rules are defined, possibly including additional variable
|
|
|
794 definitions for use by the @file{Makefile}. These always include rules
|
|
|
795 for the targets @samp{all}, @samp{binkit}, and @file{srckit}.
|
|
|
796
|
|
|
797 Although a number of facilities are available for complex libraries,
|
|
|
798 most simple packages' @file{Makefile}s contain a copyright notice, the
|
|
|
799 variable definitions mentioned above, and some boilerplate.
|
|
|
800
|
|
|
801 @example
|
|
|
802 # Makefile for apackage's lisp code
|
|
|
803
|
|
|
804 # This file is part of XEmacs.
|
|
|
805
|
|
|
806 # XEmacs is free software; you can redistribute it and/or modify it
|
|
|
807 # under the terms of the GNU General Public License as published by the
|
|
|
808 # Free Software Foundation; either version 2, or (at your option) any
|
|
|
809 # later version.
|
|
|
810
|
|
|
811 # XEmacs is distributed in the hope that it will be useful, but WITHOUT
|
|
|
812 # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
813 # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
814 # for more details.
|
|
|
815
|
|
|
816 # You should have received a copy of the GNU General Public License
|
|
|
817 # along with XEmacs; see the file COPYING. If not, write to
|
|
|
818 # the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
|
|
|
819 # Boston, MA 02111-1307, USA.
|
|
|
820
|
|
|
821 VERSION = 0.00
|
|
|
822 AUTHOR_VERSION = 0.00
|
|
|
823 MAINTAINER = A. M. Aintainer <ama@@not.a.doc>
|
|
|
824 PACKAGE = apackage
|
|
|
825 PKG_TYPE = regular
|
|
|
826 REQUIRES = xemacs-base
|
|
|
827 CATEGORY = standard
|
|
|
828
|
|
|
829 # All .els should be compiled and packaged.
|
|
|
830 ELS = $(wildcard *.el)
|
|
|
831 ELCS = $(ELS:.el=.elc)
|
|
|
832
|
|
|
833 include ../../XEmacs.rules
|
|
|
834
|
|
|
835 all:: $(ELCS) auto-autoloads.elc custom-load.elc
|
|
|
836
|
|
|
837 srckit: srckit-std
|
|
|
838
|
|
|
839 binkit: binkit-common
|
|
|
840 @end example
|
|
|
841
|
|
|
842 @menu
|
|
|
843 * package-compile.el::
|
|
|
844 * package-info.in Fields::
|
|
|
845 * Makefile Variables::
|
|
|
846 * Makefile Targets::
|
|
|
847 @end menu
|
|
|
848
|
|
|
849
|
|
|
850 @node package-compile.el, package-info.in Fields, , Creating Packages
|
|
|
851
|
|
|
852 The @xpms{} does not automatically become aware of your package simply
|
|
|
853 because there is a new subtree. If any package, including your own,
|
|
|
854 requires any of your files, it must be explicitly added to the compile
|
|
|
855 environment or loads/requires that search load-path will fail. The
|
|
|
856 changes that need to be made are
|
|
|
857
|
|
|
858 @table @strong
|
|
694
|
859 @item an entry in @code{package-directory-map}
|
|
693
|
860 This tells the @xpms{} which distribution (currently
|
|
|
861 @samp{xemacs-packages} or @samp{mule-packages}) your package is found
|
|
|
862 in. It then looks in the distribution subdirectory whose name is the
|
|
|
863 same as the package's.
|
|
|
864
|
|
|
865 @item an entry in the @code{cond} in @code{package-name-to-directory}
|
|
|
866 This is optional; it is necessary only if you keep your Lisp code
|
|
|
867 somewhere other than the top-level directory of the package's source
|
|
|
868 tree, eg, in @file{packages/xemacs-packages/@var{PACKAGE}/lisp}.
|
|
|
869 @end table
|
|
|
870
|
|
|
871 This only needs to be done once, when the package is first added to the
|
|
|
872 @xpms{}. (Well, when you randomly change the subdirectory layout, too.)
|
|
|
873 Your changes to @file{package-compile.el} must be cleared and checked in
|
|
|
874 by the XEmacs Package Release Engineer before your package will build
|
|
|
875 correctly from a fresh checkout.
|
|
|
876
|
|
694
|
877 This is unfortunate; it works pretty well once set up, but can cause
|
|
|
878 confusion when first building a package in the @xpms{} context. In
|
|
|
879 particular, if the @code{package-directory-map} entry for a required
|
|
|
880 package
|
|
|
881 @c #### including the package itself?
|
|
|
882 is not found, the necessary requires will not be executed by
|
|
|
883 @file{package-compile.el}. If required functions are executed (under
|
|
|
884 @code{eval-when-compile}), they won't be found and the compile will
|
|
|
885 fail. If required function is actually a macro, the byte compiler will
|
|
|
886 not recognize that, compile a function call to the macro. This will
|
|
|
887 cause a run-time error because the byte-code interpreter does not know
|
|
|
888 how to execute macros. (Macros can always be expanded at compile-time,
|
|
|
889 and this is more efficient.)
|
|
|
890
|
|
|
891 If your package keeps some or all Lisp code somewhere other than the top
|
|
|
892 directory, then an entry in @code{package-name-to-directory} is also
|
|
|
893 necessary, or requires will fail, leading to the problems just described.
|
|
693
|
894
|
|
|
895
|
|
|
896 @node package-info.in Fields, Makefile Variables, package-compile.el, Creating Packages
|
|
|
897
|
|
|
898 The @file{package-info.in} structure is simply Lisp data, to be read by
|
|
|
899 a Lisp script, have values substituted for variables, and then written
|
|
|
900 out (appropriately quoted) into a loadable Lisp file, to be consed into
|
|
|
901 the @file{package-index.el} list at the FTP archives. That list is
|
|
|
902 structured as an alist with package names as keys. The package data is
|
|
|
903 a plist. Do not rely on this, as it may change. If you have a good
|
|
|
904 reason for relying on it, let the maintainers know and we may
|
|
|
905 incorporate it in a future revision of the @xpms{} standard.
|
|
|
906
|
|
|
907 There are several kinds of fields, distinguished by how they get their
|
|
|
908 values. There are literals written into @file{package-info.in} by the
|
|
|
909 package maintainer. There are variables substituted in by the build
|
|
|
910 process, some computed, and others written as values of @file{make}
|
|
|
911 variables in the @file{Makefile} by the package maintainer. There are a
|
|
|
912 few implementation constants, some of which are simply the default value
|
|
|
913 for obsolete fields.
|
|
|
914
|
|
|
915 The @file{package-info.in} literals provided by the maintainer generally
|
|
|
916 should not change over the life of the package. (The exception is the
|
|
|
917 @samp{provides} field, which should be generated, but isn't yet.)
|
|
861
|
918 Values described as ``literal'' below are unquoted literal text. These
|
|
693
|
919 are normally interpreted as symbols by the package build process. The
|
|
|
920 maintainer literals are
|
|
|
921
|
|
|
922 @table @asis
|
|
|
923 @item @var{package_name}
|
|
|
924 A literal. The only unnamed ``field,'' the name of the package.
|
|
|
925
|
|
|
926 @item distribution
|
|
|
927 A literal, either @samp{xemacs} (for generic packages) or @samp{mule}
|
|
|
928 (for packages requiring Mule). @xref{Package Terminology}.
|
|
|
929
|
|
|
930 @item description
|
|
|
931 A Lisp string containing a one-line text description for use in package
|
|
|
932 listings.
|
|
|
933
|
|
|
934 @item provides
|
|
|
935 A (Lisp) list of features provided by the libraries in the package. All
|
|
|
936 of the features provided by libraries in your package should be elements
|
|
|
937 of this list.
|
|
|
938
|
|
|
939 @item type
|
|
|
940 A literal, either @samp{regular} or @samp{single-file}. For practical
|
|
|
941 purposes, @samp{regular} should be considered an implementation constant.
|
|
|
942 @end table
|
|
|
943
|
|
|
944 @c #### The following should be rewritten to @xref the make variables
|
|
|
945 @c node, and simply associate the field names to the make variables with
|
|
|
946 @c one line of description.
|
|
|
947 Values which are expected to change regularly as the package is enhanced
|
|
|
948 are implemented as @file{make} variables. You should not change them in
|
|
|
949 the @file{package-info.in} file; they are automatically filled in by the
|
|
|
950 build process.
|
|
|
951
|
|
|
952 The corresponding field name is given in parentheses. These include
|
|
|
953
|
|
|
954 @table @code
|
|
|
955 @item VERSION
|
|
|
956 (version)
|
|
|
957 The version of the XEmacs package, a numeric literal (a decimal
|
|
|
958 fixed-point number with two-places of precision).
|
|
|
959
|
|
|
960 @item AUTHOR_VERSION
|
|
|
961 (author-version)
|
|
|
962 The upstream author's version, an unintepreted literal.
|
|
|
963
|
|
|
964 @item DATE
|
|
|
965 (date)
|
|
|
966 Date of release of the upstream version.
|
|
|
967
|
|
|
968 @item MAINTAINER
|
|
|
969 (maintainer)
|
|
|
970 A literal containing the XEmacs package's maintainer and his/her email
|
|
|
971 address.
|
|
|
972
|
|
|
973 @item CATEGORY
|
|
|
974 (category)
|
|
|
975 A literal, either @samp{standard} or @samp{mule}. Probably redundant.
|
|
|
976
|
|
|
977 @item REQUIRES
|
|
|
978 (requires)
|
|
|
979 A list of packages required to correctly build this package.
|
|
|
980
|
|
|
981 Note that the usual form in @file{package-info.in} already has the
|
|
|
982 parentheses, so the @file{make} variable should be set to a
|
|
|
983 space-separated list of package names @emph{not} enclosed in
|
|
|
984 parentheses.
|
|
|
985
|
|
|
986 The list is of @emph{packages}, not @emph{libraries}, as would
|
|
|
987 ordinarily be provided to the Lisp @code{require} function.
|
|
|
988
|
|
|
989 @samp{REQUIRES} cannot be correctly computed from the calls to
|
|
|
990 @code{require} in the package's library sources. @samp{REQUIRES} is
|
|
|
991 used to ensure that all macro and defstruct definitions used by the
|
|
|
992 package are available at build time. This is not merely a matter of
|
|
|
993 efficiency, to get the expansions inlined. In fact, it is
|
|
|
994 @emph{impossible} to call a macro by name in byte-compiled Emacs Lisp
|
|
|
995 code. Thus, if the macro expansion is not inlined, the call will result
|
|
|
996 in an error at run-time! Thus, packages providing libraries that would
|
|
|
997 be loaded because of autoload definitions must also be included.
|
|
|
998
|
|
|
999 On the other hand, if a package provides no macros to this package, it
|
|
|
1000 is preferable @emph{not} to include it in @samp{REQUIRES}, because it is
|
|
|
1001 not uncommon that if the developer doesn't normally use the required
|
|
|
1002 package, he will never use the functionality in the package being built,
|
|
|
1003 either. In that case it would be preferable to not require the
|
|
|
1004 developer to have source for the dependencies. That said, of course it
|
|
|
1005 is safe to put too many packages in @samp{REQUIRES}.
|
|
|
1006 @end table
|
|
|
1007
|
|
|
1008 Values for the following fields are automatically generated by the build
|
|
|
1009 process.
|
|
|
1010
|
|
|
1011 @table @asis
|
|
|
1012 @item build-date
|
|
|
1013 The date the package tarball was generated.
|
|
|
1014
|
|
|
1015 @item md5sum
|
|
|
1016 An MD5 checksum for the package tarball, as gzipped.
|
|
|
1017
|
|
|
1018 @item size
|
|
|
1019 The size of the package tarball, as gzipped.
|
|
|
1020 @end table
|
|
|
1021
|
|
|
1022 It is not clear that either md5sum or size works correctly if the
|
|
|
1023 @samp{BZIP2} variable in @file{Local.rules} is set.
|
|
|
1024
|
|
|
1025 The implementation constants are
|
|
|
1026
|
|
|
1027 @table @asis
|
|
|
1028 @item standards-version
|
|
|
1029 Currently 1.1. Defines the format of the @file{package-info.in} file
|
|
|
1030 and the @file{Makefile}. A true implementation constant.
|
|
|
1031
|
|
|
1032 @item priority
|
|
|
1033 An unimplemented and underspecified feature. Suggestions for
|
|
|
1034 specification and implementation welcome.
|
|
|
1035
|
|
|
1036 @item dump
|
|
|
1037 An obsolete feature, superseded by the @file{site-load.el} mechanism.
|
|
|
1038 The value should always be nil.
|
|
|
1039
|
|
|
1040 @item filename
|
|
|
1041 An obsolete feature, completely ignored. Don't even think about doing
|
|
|
1042 anything useful with it.
|
|
|
1043 @end table
|
|
|
1044
|
|
|
1045
|
|
|
1046 @node Makefile Variables, Makefile Targets, package-info.in Fields, Creating Packages
|
|
|
1047
|
|
|
1048 A number of @file{make} variables are defined by the @xpms{}. Some are
|
|
|
1049 required, others are optional. Of course your @file{Makefile} may
|
|
|
1050 define other variables for private use, but you should be careful not to
|
|
|
1051 choose names that conflict with variables defined and used by the
|
|
|
1052 @xpms{}.
|
|
|
1053
|
|
|
1054 The required variables are described in the table below.
|
|
|
1055 The corresponding field names for @file{package-info.in}, where
|
|
|
1056 relevant, are given in parentheses.
|
|
|
1057
|
|
749
|
1058 @c This is the canonical place for this information. If there is
|
|
693
|
1059 @c unnecessary duplication with package-info.in documentation, shorten
|
|
|
1060 @c that and leave this full-length.
|
|
|
1061 @table @code
|
|
|
1062 @item VERSION
|
|
|
1063 (version)
|
|
|
1064 The version of the XEmacs package, a numeric literal (a decimal
|
|
|
1065 fixed-point number with two-places of precision).
|
|
|
1066
|
|
|
1067 @item AUTHOR_VERSION
|
|
|
1068 (author-version)
|
|
|
1069 The upstream author's version, an unintepreted literal.
|
|
|
1070
|
|
|
1071 @item DATE
|
|
|
1072 (date)
|
|
|
1073 Date of release of the upstream version.
|
|
|
1074
|
|
|
1075 @item MAINTAINER
|
|
|
1076 (maintainer)
|
|
|
1077 A literal containing the XEmacs package's maintainer and his/her email
|
|
|
1078 address.
|
|
|
1079
|
|
|
1080 @item CATEGORY
|
|
|
1081 (category)
|
|
|
1082 A literal, either @samp{standard} or @samp{mule}. Probably redundant.
|
|
|
1083
|
|
|
1084 @item REQUIRES
|
|
|
1085 (requires)
|
|
|
1086 A list of packages required to correctly build this package.
|
|
|
1087
|
|
|
1088 Note that the usual form in @file{package-info.in} already has the
|
|
|
1089 parentheses, so the @file{make} variable should be set to a
|
|
|
1090 space-separated list of package names @emph{not} enclosed in
|
|
|
1091 parentheses.
|
|
|
1092
|
|
|
1093 The list is of @emph{packages}, not @emph{libraries}, as would
|
|
|
1094 ordinarily be provided to the Lisp @code{require} function.
|
|
|
1095
|
|
|
1096 @samp{REQUIRES} cannot be correctly computed from the calls to
|
|
|
1097 @code{require} in the package's library sources. @samp{REQUIRES} is
|
|
|
1098 used to ensure that all macro and defstruct definitions used by the
|
|
|
1099 package are available at build time. This is not merely a matter of
|
|
|
1100 efficiency, to get the expansions inlined. In fact, it is
|
|
|
1101 @emph{impossible} to call a macro by name in byte-compiled Emacs Lisp
|
|
|
1102 code. Thus, if the macro expansion is not inlined, the call will result
|
|
|
1103 in an error at run-time! Thus, packages providing libraries that would
|
|
|
1104 be loaded because of autoload definitions must also be included.
|
|
|
1105
|
|
|
1106 On the other hand, if a package provides no macros to this package, it
|
|
|
1107 is preferable @emph{not} to include it in @samp{REQUIRES}, because it is
|
|
|
1108 not uncommon that if the developer doesn't normally use the required
|
|
|
1109 package, he will never use the functionality in the package being built,
|
|
|
1110 either. In that case it would be preferable to not require the
|
|
|
1111 developer to have source for the dependencies. That said, of course it
|
|
|
1112 is safe to put too many packages in @samp{REQUIRES}.
|
|
|
1113
|
|
|
1114 @item ELCS
|
|
|
1115 The list of the byte-compiled Lisp files used by the package. These
|
|
|
1116 files and their @file{.el} versions will be included in the binary
|
|
|
1117 package. This variable determines which libraries will be
|
|
|
1118 byte-compiled. These libraries are also deleted by @samp{make clean}.
|
|
|
1119
|
|
|
1120 Note there is no sanity-checking done on this variable. If you put
|
|
|
1121 @samp{.el} files in here, they will not be compiled and they @emph{will}
|
|
|
1122 be deleted by @samp{make clean}. You would surely be very distressed if
|
|
|
1123 that happened, so be very careful. If this variable is left empty, none
|
|
|
1124 of your Lisp code will be compiled or packaged. This would be a less
|
|
|
1125 than amusing surprise, too.
|
|
|
1126
|
|
|
1127 We don't consider this a feature, of course. Please do submit code to
|
|
|
1128 do sanity checking to @email{xemacs-patches@@xemacs.org}.
|
|
|
1129 @end table
|
|
|
1130
|
|
749
|
1131 Optional, but very commonly used variables are explained below.
|
|
693
|
1132
|
|
|
1133 @table @code
|
|
|
1134 item EXTRA_SOURCES
|
|
|
1135 Other files (such as extra Lisp sources or an upstream @file{Makefile})
|
|
|
1136 that are normally placed in the installed Lisp directory, but not
|
|
|
1137 byte-compiled. These files are @emph{preserved} by the @samp{clean}
|
|
|
1138 targets.
|
|
|
1139
|
|
|
1140 @item EXTRA_OBJS
|
|
|
1141 Other files (such as compiled autoload or concatenated @file{.elc}
|
|
|
1142 libraries) which are normally placed in the installed Lisp directory,
|
|
|
1143 but do @emph{not} have corresponding source files and @emph{should} be
|
|
|
1144 deleted by the @samp{clean} targets. Some of these (such as
|
|
|
1145 package-specific autoload setups) can and probably should be replaced by
|
|
|
1146 @xpms{} solutions such as @file{auto-autoloads.el}, but many cannot.
|
|
|
1147
|
|
|
1148 @item PRELOADS
|
|
|
1149 A specification for loading libraries containing macros before compiling
|
|
|
1150 the Lisp in the package. This is spliced directly into the invocation
|
|
|
1151 of XEmacs for byte-compilation, so it must contain the @samp{-l} flag
|
|
|
1152 for XEmacs:
|
|
|
1153
|
|
|
1154 @example
|
|
|
1155 PRELOADS=-l ./apackage-macros.el -l ../bpackage/lisp/bpackage-macros.el
|
|
|
1156 @end example
|
|
|
1157
|
|
749
|
1158 Preloads are loaded before @file{package-compile.el}, so the
|
|
|
1159 @var{load-path} is minimal. Therefore @samp{PRELOADS} must specify a
|
|
|
1160 full path to packaged Lisp. The base @var{load-path} does include the
|
|
|
1161 core Lisp directory, so core libraries are found.
|
|
|
1162
|
|
693
|
1163 @item INFO_FILES
|
|
|
1164 Any Info file(s) generated by the package. These must be paths relative
|
|
|
1165 to the root of the package's source tree.
|
|
|
1166
|
|
|
1167 @item TEXI_FILES
|
|
|
1168 The Texinfo source file(s). These must be paths relative
|
|
|
1169 to the root of the package's source tree.
|
|
|
1170
|
|
|
1171 @item MANUAL
|
|
|
1172 The name to be used for Info files and man pages.
|
|
|
1173
|
|
|
1174 @item DATA_FILES
|
|
|
1175 Any data files, such as pixmaps, READMEs, and ChangeLogs. These must be
|
|
749
|
1176 paths relative to the root of the package's source tree. These files
|
|
|
1177 will be copied to @samp{$(DATA_DEST)} for installation. Any directory
|
|
752
|
1178 component of the path for a file will be stripped, so that the
|
|
749
|
1179 file ends up in @samp{$(DATA_DEST)}, not in a subdiredtory. If there are
|
|
|
1180 several destination directories, the forms @samp{$(DATA_FILES_@var{n})}
|
|
|
1181 and @samp{$(DATA_DEST_@var{n})} (@var{n} may take values in 1-40) must
|
|
|
1182 be used. The @xpms{} doesn't make provision for copying trees at this
|
|
|
1183 time.
|
|
693
|
1184
|
|
|
1185 @item DATA_DEST
|
|
|
1186 The installation location for data files, relative to the @file{etc/}
|
|
749
|
1187 directory of the package hierarchy. The default is currently empty, but
|
|
|
1188 the normal value is simply $(PACKAGE). Leaving it empty (@emph{i.e.},
|
|
|
1189 put it directly under @file{etc/}) will probably work, but is subject to
|
|
|
1190 name conflicts with other packages. If there are several destination
|
|
|
1191 directories, the form @samp{$(DATA_DEST_@var{n})} must be used. The
|
|
|
1192 @xpms{} doesn't make provision for copying trees at this time.
|
|
|
1193 @end table
|
|
|
1194
|
|
|
1195 The following variables are defaulted by @file{Local.rules} or
|
|
|
1196 @file{XEmacs.rules}. These variables often should be added to using
|
|
|
1197 @samp{+=} rather than set by @samp{=} or @samp{:=}.
|
|
|
1198
|
|
|
1199 @table @code
|
|
|
1200 @item GENERATED
|
|
|
1201 @c #### Is this correct?
|
|
|
1202 A list of @file{.elc} files compiled from @file{.el} files generated by
|
|
|
1203 the package build process. These files and the corresponding @file{.el}
|
|
|
1204 files are copied to the installed @file{lisp} directory. Defaults to
|
|
|
1205 @samp{$@{AUTOLOAD_PATH@}/auto-autoloads.elc}. Typical usage is
|
|
|
1206 @example
|
|
|
1207 GENERATED += $@{AUTOLOAD_PATH@}/custom-load.elc
|
|
|
1208 @end example
|
|
693
|
1209 @end table
|
|
|
1210
|
|
|
1211 Rarely used variables.
|
|
|
1212
|
|
|
1213 @c @table @code
|
|
|
1214 @c @item
|
|
|
1215 @c @end table
|
|
|
1216
|
|
|
1217 @node Makefile Targets, , Makefile Variables, Creating Packages
|
|
|
1218
|
|
|
1219 The standard targets that need to be defined in your @file{Makefile}
|
|
|
1220 follow. These normally should @emph{not} have an action. All of the
|
|
|
1221 work should be done by dependent targets, usually having standard
|
|
|
1222 definitions in the @xpms{}.
|
|
|
1223
|
|
|
1224 @table @samp
|
|
|
1225 @item all
|
|
|
1226 A list of generated files, usually byte-compiled Lisp libraries, to be
|
|
|
1227 bundled in the package. The typical dependencies are
|
|
|
1228
|
|
|
1229 @example
|
|
|
1230 $(ELCS) auto-autoloads.elc custom-load.elc
|
|
|
1231 @end example
|
|
|
1232
|
|
|
1233 Other targets (such as Info files) may need to be added as dependencies
|
|
|
1234 for the @code{all} target.
|
|
|
1235
|
|
|
1236 @item srckit
|
|
|
1237 The target for generating a source package. Not implemented. If it
|
|
|
1238 were, the normal dependency would be @samp{srckit-std}.
|
|
|
1239
|
|
|
1240 @item binkit
|
|
|
1241 The target for creating a ``master'' installation. Binary packages are
|
|
|
1242 actually generated by the @samp{bindist} target. @xref{Building Packages}.
|
|
|
1243 @end table
|
|
|
1244
|
|
|
1245 Standard dependencies for @code{srckit} and @code{binkit} are defined in
|
|
|
1246 @file{XEmacs.rules}. The most useful of these values are given in the
|
|
|
1247 following table.
|
|
|
1248
|
|
|
1249 @table @samp
|
|
|
1250 @item srckit-std
|
|
|
1251 Build a standard source kit. Not fully implemented.
|
|
|
1252
|
|
|
1253 @item binkit-sourceonly
|
|
|
1254 The @samp{binkit} target need only install source and compiled Lisp in
|
|
|
1255 the staging area. There is nothing to install in a data directory or
|
|
|
1256 info directory.
|
|
|
1257
|
|
|
1258 @item binkit-sourceinfo
|
|
|
1259 Both source and info files are to be installed in the staging area.
|
|
|
1260
|
|
|
1261 @item binkit-sourcedata
|
|
|
1262 Both source and etc (data) files are to be installed in the staging
|
|
|
1263 area.
|
|
|
1264
|
|
|
1265 @item binkit-sourcedatainfo
|
|
|
1266 Source, etc (data), and info files all are present and need to be
|
|
|
1267 installed in the staging area.
|
|
|
1268
|
|
|
1269 @item binkit-common
|
|
|
1270 A dependency for all the above. (In fact in the current implementation
|
|
|
1271 @samp{binkit-common} does all the work for all of the @samp{binkit}
|
|
|
1272 targets.)
|
|
|
1273 @end table
|
|
|
1274
|
|
|
1275 Data files include things like pixmaps for a package-specific toolbar,
|
|
|
1276 and are normally installed in @file{etc/@var{PACKAGE_NAME}}. A few
|
|
|
1277 packages have needs beyond the basic templates. See @file{XEmacs.rules}
|
|
|
1278 or a future revision of this manual for details.
|
|
|
1279
|
|
|
1280
|
|
752
|
1281 @node Documenting Packages, Issues, Creating Packages, Packaging
|
|
|
1282 @comment node-name, next, previous, up
|
|
|
1283 @cindex documenting packages
|
|
|
1284 @heading Documenting Packages:
|
|
|
1285
|
|
|
1286 @c #### Add a documentation section to Internals, and xref here.
|
|
|
1287 Some random notes on documenting your package.
|
|
|
1288
|
|
|
1289 Do write a Texinfo file. It's not that hard to do basically, and even
|
|
|
1290 using the more advanced features of Texinfo soon become natural. For a
|
|
|
1291 start, just grab the template @file{Samples/package.texi} from the
|
|
|
1292 @xpms{} source tree, and drop your current README into the Top node. At
|
|
|
1293 least this way your documentation will be accessible from the standard
|
|
|
1294 Info readers. Next, try to add lots of cross-referencing and logical
|
|
|
1295 markup, and then node structure.
|
|
|
1296
|
|
|
1297 Address both end users and developer issues. You may not be the
|
|
|
1298 maintainer forever.
|
|
|
1299
|
|
|
1300 If you are maintaining a package that is part of the GNU Emacs
|
|
|
1301 distribution, you'll likely find that you occasionally synchronize your
|
|
|
1302 package with the GNU Emacs sources. When you synch a file,
|
|
|
1303 conventionally you should place a comment just above the standard
|
|
|
1304 @code{;;; Code} comment that looks like this:
|
|
|
1305
|
|
|
1306 @example
|
|
|
1307 ;; Synched with:
|
|
|
1308 ;; GNU Emacs 21.1, 2002-02-08, Stephen Turnbull <stephen@@xemacs.org>
|
|
|
1309 @end example
|
|
|
1310
|
|
|
1311 This comment is a status flag; the ChangeLog doesn't really give the
|
|
|
1312 same information.
|
|
|
1313
|
|
|
1314 Do maintain a detailed ChangeLog.
|
|
|
1315
|
|
|
1316 @node Issues, , Documenting Packages, Packaging
|
|
693
|
1317 @section Issues
|
|
|
1318
|
|
694
|
1319 To be completed.
|
|
693
|
1320
|
