Mercurial > hg > xemacs-beta
annotate man/lispref/packaging.texi @ 5888:a85efdabe237
Call #'read-passwd when requesting a password from the user, tls.c
src/ChangeLog addition:
2015-04-09 Aidan Kehoe <kehoea@parhasard.net>
* tls.c (nss_pk11_password):
* tls.c (gnutls_pk11_password):
* tls.c (openssl_password):
* tls.c (syms_of_tls):
Our read-a-password function is #'read-passwd, not
#'read-password, correct that in this file.
| author | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| date | Thu, 09 Apr 2015 14:54:37 +0100 |
| parents | 9c17f7be0b92 |
| children |
| rev | line source |
|---|---|
| 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 | |
| 2955 | 11 @set xpms XE@sc{macs} Packaging System |
| 693 | 12 @end iftex |
| 13 @ifnottex | |
| 2955 | 14 @set xpms XEmacs Packaging System |
| 693 | 15 @end ifnottex |
| 16 | |
| 17 @node Packaging, Lisp Data Types, Introduction, Top | |
| 2955 | 18 @chapter The @value{xpms} |
| 693 | 19 @cindex package |
| 20 @cindex packaging | |
| 21 | |
| 22 The XEmacs distribution, starting with version 21, comes only with a | |
| 23 very basic set of built-in modes and libraries. Most of the libraries | |
| 24 that were part of the distribution of earlier versions of XEmacs are now | |
| 25 available separately. The user as well as the system administrator can | |
| 26 choose which packages to install; the actual installation process is | |
| 27 easy. This gives an installer the ability to tailor an XEmacs | |
| 28 installation for local needs with safe removal of unnecessary code. | |
| 29 | |
| 30 This chapter describes how to package Lisp libraries for use with the | |
| 2955 | 31 @value{xpms}. |
| 693 | 32 |
| 33 @emph{Please note carefully} that the term @dfn{package} as used in | |
| 34 XEmacs refers to an aggregation of Lisp code and/or data distributed as | |
| 35 a unit. It does not, as it does in many Lisps, refer to a way of | |
| 36 creating separate name spaces. XEmacs has no facility for providing | |
| 37 separate name spaces. (If we ever do get separate name spaces, we'll | |
| 38 probably regret overloading the nomenclature in this way, but it's | |
| 39 become established.) | |
| 40 | |
| 41 @menu | |
| 42 Introduction: | |
| 1648 | 43 * Package Overview:: Lisp Libraries and Packages. |
| 693 | 44 |
| 45 Packaging Lisp Libraries: | |
| 1648 | 46 * Package Terminology:: Basic stuff. |
| 47 * Building Packages:: Turn packaged source into a tarball. | |
| 48 * Makefile Targets:: Package @file{Makefile} targets | |
| 2955 | 49 * Local.rules File:: Tell the @value{xpms} about your host. |
| 50 * Creating Packages:: Tell the @value{xpms} about your package. | |
| 1648 | 51 * Documenting Packages:: Explain your package to users and hackers. |
| 2955 | 52 @c * History:: History of the @value{xpms} |
| 53 @c * Installation:: Installing the @value{xpms} with your (X)Emacs. | |
| 54 @c * Configuration:: Configuring the @value{xpms} for use. | |
| 55 @c * Usage:: An overview of the operation of the @value{xpms}. | |
| 693 | 56 @c * Bug Reports:: Reporting Bugs and Problems |
| 57 @c * Frequently Asked Questions:: Questions and answers from the mailing list. | |
| 58 | |
| 59 Internals and Package Release Engineering: | |
| 60 * Issues:: | |
| 61 @end menu | |
| 62 | |
| 63 @node Package Overview, Package Terminology, , Packaging | |
| 2955 | 64 @chapter An overview of the @value{xpms} |
| 693 | 65 |
| 2955 | 66 The @value{xpms} is a system for administering the installation, upgrade, and |
| 693 | 67 removal of Lisp libraries. For the end user, it provides facilities for |
| 68 determining availability of packages and which versions at remote | |
| 69 sites. It will download and automatically install a package, ensuring | |
| 70 that any old files from previous versions of the package are removed | |
| 71 first. By providing a standard set of hierarchies for installation, it | |
| 72 makes configuration of XEmacs simpler. Furthermore, packages normally | |
| 73 provide ancillary auto-autoloads and custom-loads libraries, which are | |
| 74 automatically detected and loaded by XEmacs upon startup. This means | |
| 75 that once installed, all facilities of package, including autoloading | |
| 76 the library upon invocation of a command provided by the library and | |
| 77 convenient configuration and customization, are automatically available | |
| 78 to the user. There is no need to add autoloads or keybindings to in the | |
| 79 init file, and structured configuration of the package is available | |
| 80 through the Customize system even before the libraries are loaded. | |
| 81 | |
| 82 All of this convenience comes at a cost. The cost of administration at | |
| 83 the package level is negligible compared to the benefits, of course. | |
| 84 However, the requirement that XEmacs find and load auto-autoloads and | |
| 85 custom-loads libraries comes at a fairly large cost in startup time. In | |
| 86 order to reduce this cost, XEmacs imposes fairly strict conditions on | |
| 87 the structure of an installed package. | |
| 88 | |
| 89 Meeting these requirements, as well as simply providing the | |
| 90 auto-autoloads and the information about availability and so on does | |
| 2955 | 91 impose some costs on the library maintainer. The @value{xpms} also provides |
| 693 | 92 structure and utilities to the library maintainer to make these tasks |
| 93 easier. This manual documents the requirements and the tools that the | |
| 2955 | 94 @value{xpms} provides to ensure that a package satisfies them. |
| 693 | 95 |
| 96 @menu | |
| 759 | 97 * The User View:: |
| 98 * The Library Maintainer View:: | |
| 99 * The Package Release Engineer View:: | |
| 693 | 100 @end menu |
| 101 | |
| 102 | |
| 759 | 103 @node The User View, The Library Maintainer View, , Package Overview |
| 104 @section The User View | |
| 693 | 105 |
| 106 @strong{N.B.} Much of the discussion in this section undoubtedly | |
| 107 belongs elsewhere, @ref{Packages,,,xemacs}. | |
| 108 | |
| 109 From the user's point of view, an XEmacs binary package is simply a | |
| 110 standard tarball (usually gzipped) containing Lisp sources, compiled | |
| 111 Lisp, documentation, and possibly data files or supporting executables. | |
| 112 The tarball is unpacked using standard tools such as GNU tar and gzip. | |
| 113 The package system does impose certain requirements for automatic | |
| 114 configuration to work. | |
| 115 | |
| 116 Here the main consideration is that the tarball ``expects'' to be | |
| 117 unpacked from the top of a package hierarchy. A @dfn{package hierarchy} | |
| 118 is basically an image of a classic Emacs ``run-in-place'' tree, with | |
| 119 @file{lisp}, @file{etc}, @file{info}, @file{man}, @file{lib-src}, and | |
| 120 @file{pkginfo} subdirectories of the top. The @file{pkginfo} | |
| 2955 | 121 subdirectory is for use by the @value{xpms} administration tools, and |
| 693 | 122 currently contains a @file{MANIFEST.@var{package-name}} file for each |
| 123 package to ensure that no cruft remains when a package is removed or | |
| 124 updated. The @file{lisp}, @file{etc}, and @file{lib-src} subdirectories | |
| 125 are further subdivided, with a subdirectory for each package. The | |
| 694 | 126 @file{info} directory obeys the usual conventions. |
| 127 @emph{I.e.}, the @file{info} directory is flat | |
| 693 | 128 with a(n) (optional) @file{dir} file and one (set of) info file(s) per |
| 694 | 129 package. The @file{man} subdirectory typically contains documentation |
| 130 sources, separated by package. (It does not contain @file{man(1)} | |
| 131 pages, as Emacs provides very few of them.) | |
| 693 | 132 |
| 133 There are several standard package hierarchies, and administrators can | |
| 134 configure others at build time, while users can configure others at run | |
| 135 time. The standard system hierarchies are all subdirectories of an | |
| 136 @c #### This is possibly incorrect usage of "installation root." | |
| 137 XEmacs installation root, typically @file{/usr/local/lib/xemacs/}. | |
| 138 These are the @file{xemacs-packages}, @file{mule-packages}, | |
| 139 @file{infodock-packages}, and @file{site-packages} hierarchies. Each | |
| 140 has the structure described above, but the purposes differ. The | |
| 141 @file{xemacs-packages} is the normal place for installing ``official'' | |
| 142 packages and many third-party libraries. Unfortunately, it is not yet | |
| 143 quite possible to read libraries containing international characters | |
| 144 with a non-Mule XEmacs, so such libraries are sequestered in the | |
| 145 @file{mule-packages} hierarchy. Some packages are compatible only with | |
| 146 the Infodock development environment, and they will be installed in the | |
| 147 @file{infodock-packages} hierarchy. The @file{site-packages} hierarchy | |
| 148 is for packages not distributed by XEmacs.org, typically locally | |
| 149 developed. | |
| 150 | |
| 151 Packages are in principle supposed to be XEmacs version-independent, but | |
| 152 if such dependencies are unavoidable, additional standard package | |
| 153 hierarchies may be installed under version directories, @emph{e.g.} | |
| 154 @file{/usr/local/lib/xemacs-21.4.6/}. | |
| 155 | |
| 156 Users who do not have sufficient privilege to install packages in the | |
| 1648 | 157 system hierarchies may install package hierarchies under @file{~/.xemacs}. |
| 158 At present only the @file{xemacs-packages}, @file{mule-packages}, and | |
| 159 @file{site-packages} hierarchies are supported, but it might make sense to | |
| 160 extend this to support @file{infodock-packages} hierarchies in the future. | |
| 693 | 161 |
| 162 The package hierarchies are not searched directly for libraries to be | |
| 163 loaded; this would be very costly. Instead, the hierarchies are ordered | |
| 164 according to certain rules, and searched for package lisp directories at | |
| 165 invocation. These directories are added to the general | |
| 166 @code{load-path}. As usual, it is @code{load-path} that is searched at | |
| 167 run-time. This approach is somewhat costly at initialization, but | |
| 168 results in a very ``clean'' @code{load-path}. | |
| 169 | |
| 170 The order of search can be changed at build time by specifying the | |
| 3179 | 171 @samp{--with-user-packages} (an alias for @samp{--with-early-packages}), |
| 172 @samp{--with-system-packages} (an alias for | |
| 173 @samp{--with-late-packages}), and @samp{--with-legacy-packages} (an | |
| 174 alias for @samp{--with-last-packages}) options to @file{configure}, or | |
| 175 at run-time by specifying the @code{EMACSEARLYPACKAGES}, | |
| 176 @code{EMACSLATEPACKAGES}, @code{EMACSLASTPACKAGES} environment | |
| 177 variables. @xref{Packages,,,xemacs}. | |
| 693 | 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 |
| 2955 | 245 From the library maintainer's viewpoint, the advantages to the @value{xpms} |
| 693 | 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 | |
| 2955 | 255 requirements of the @value{xpms}. Autoload cookies and defcustoms must also |
| 256 be added to existing libraries. The @value{xpms} provides infrastructure to | |
| 693 | 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 | |
| 2955 | 262 The @value{xpms} may be divided into the @dfn{infrastructure} common to all |
| 693 | 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 | |
| 1648 | 270 * Infrastructure:: Global Makefiles and common rules. |
| 271 * Control Files:: Package-specific Makefiles and administrative files. | |
| 2955 | 272 * Obtaining:: Obtaining the @value{xpms} and required utilities. |
| 693 | 273 @end menu |
| 274 | |
| 759 | 275 @node Infrastructure, Control Files, , The Library Maintainer View |
| 693 | 276 @subsection Infrastructure |
| 277 | |
| 2955 | 278 In order to get the greatest benefit from the @value{xpms}, a library |
| 693 | 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 | |
| 1648 | 328 @item meta-iterate.rules |
| 329 This is used by higher-level subdirectories that do not directly | |
| 330 contain packages. Subdirectories directly containing packages should | |
| 331 use iterate.rules instead. | |
| 332 | |
| 693 | 333 @item XEmacs.rules |
| 334 provides the rules for building and packaging. Included by all package | |
| 335 @file{Makefile}s. | |
| 336 | |
| 337 @item Local.rules | |
| 338 provides local configuration, such as installation targets and staging | |
| 339 directories, as well as a number of kludges (many now obsolete) required | |
| 340 for building packages on the Windows platform. | |
| 341 | |
| 342 @item Local.rules.template | |
| 343 a template for Local.rules, liberally commented | |
| 344 | |
| 345 @item Local.rules.mk | |
| 346 consistency checking for @file{Local.rules}, included by both the | |
| 347 top-level @file{Makefile} and by @file{XEmacs.rules}. | |
| 348 | |
| 1648 | 349 @item Local.rules.inc |
| 350 a file to @code{include} in package @file{Makefile}s to be able to get | |
| 351 at variables in @file{Local.rules} @emph{before} including | |
| 352 @file{XEmacs.rules}. | |
| 353 | |
| 693 | 354 @c #### Add to "issues" |
| 355 @item package-compile.el | |
| 1648 | 356 compile environment (@emph{e.g.}, load-path) setup. |
| 693 | 357 @end table |
| 358 | |
| 359 Of these, only @file{Local.rules} and @file{package-compile.el} need to | |
| 360 be modified by the library maintainer. The changes to Local.rules | |
| 361 affect only your environment. This should need to be done only once | |
| 362 when first preparing the source environment. The necessary | |
| 363 modifications to @file{package-compile.el} need to be done for each | |
| 364 package and are discussed in the next section, @ref{Control Files}. | |
| 365 | |
| 366 | |
| 759 | 367 @node Control Files, Obtaining, Infrastructure, The Library Maintainer View |
| 693 | 368 @subsection Control Files |
| 369 | |
| 370 Each package source must contain a number of control files in the | |
| 371 top-level directory. These files in general can be created and then | |
| 372 ignored, except for a few variables that need to be updated when new | |
| 373 versions are released. In most cases even adding, renaming, and | |
| 374 removing library source files can be handled by generic rules. | |
| 375 | |
| 376 The package control files include | |
| 377 | |
| 378 @table @file | |
| 379 @item Makefile | |
| 380 Must set a few @file{make} variables used by the administrative | |
| 381 utilities, and defines a couple of package-building targets to depend on | |
| 382 appropriate targets defined generically in @file{XEmacs.rules}. It may | |
| 383 also provide various variables and rules to transform the source tree | |
| 384 structure into that expected by the run-time system. | |
| 385 | |
| 386 @item package-info.in | |
| 387 Provides a template for package information to be provided to the | |
| 388 administrative utilities. Static variables that are rarely changed | |
| 389 (such as the package's name) are entered as literals. Some variables | |
| 390 are generated by the build process (build dates and MD5 checksums) and | |
| 391 are automatically filled in. Finally, some variables that change | |
| 392 irregularly (dependences and even version numbers) are set as | |
| 393 @file{make} variables in the @file{Makefile}. | |
| 394 | |
| 395 @item ChangeLog | |
| 396 Not strictly required, but normally a ChangeLog will be added by the | |
| 397 XEmacs package maintainer if different from the upstream maintainer. | |
| 398 | |
| 399 @item _pkg.el | |
| 400 Generated. Simply does a @code{package-provide} for the package. | |
| 401 | |
| 1648 | 402 @item auto-autoloads.el |
| 693 | 403 Generated. Read when XEmacs is initialized, and provides autoloads for |
| 1648 | 404 defuns and other forms in the sources that are marked with an |
| 405 @dfn{autoload cookie} (@samp{;;;###autoload}. | |
| 693 | 406 |
| 407 @item custom-loads.el | |
| 408 Generated. Read when XEmacs is initialized, and informs the Customize | |
| 409 subsystem how to find the defcustom forms needed to create Customization | |
| 410 forms for the usre configuration variables of the package. | |
| 411 @end table | |
| 412 | |
| 413 | |
| 759 | 414 @node Obtaining, , Control Files, The Library Maintainer View |
| 2955 | 415 @subsection Obtaining the @value{xpms} and Required Utilities |
| 693 | 416 |
| 417 Currently both the infrastructure for creating XEmacs packages and the | |
| 418 package sources themselves are available only by CVS. See | |
| 419 @uref{http://www.xemacs.org/Develop/cvsaccess.html} for more | |
| 420 intformation. | |
| 421 | |
| 2955 | 422 The @value{xpms} currently requires GNU @file{make}, and XEmacs, to build |
| 1648 | 423 packages. |
| 693 | 424 |
| 425 | |
| 759 | 426 @node The Package Release Engineer View, , The Library Maintainer View, Package Overview |
| 427 @subsection The Package Release Engineer View | |
| 693 | 428 |
| 694 | 429 The XEmacs Package Release Engineer is responsible for keeping the |
| 430 system coherent. The changes to @file{packages/package-compile.el} and | |
| 431 @file{packages/xemacs-packages/Makefile} required to make the package | |
| 432 available to others, and for building SUMO tarballs, @emph{etc}, are | |
| 433 done by the Package Release Engineer, not individual library | |
| 434 maintainers. | |
| 693 | 435 |
| 694 | 436 The Package Release Engineer also maintains assorted infrastructure for |
| 437 actually making releases. These are generally available for inspection | |
| 438 in the @code{xemacs-builds} module in the CVS repository. | |
| 439 | |
| 440 @c #### To be completed. | |
| 693 | 441 |
| 442 | |
| 443 @node Package Terminology, Building Packages, Package Overview, Packaging | |
| 444 @comment node-name, next, previous, up | |
| 445 @heading Package Terminology: | |
| 446 | |
| 447 @subsection Libraries and Packages | |
| 448 @cindex library | |
| 449 @cindex package | |
| 450 | |
| 451 A Lisp @dfn{library} is a single loadable file containing Lisp code. It | |
| 452 may be in source or byte-compiled form. A Lisp @dfn{package} is a set | |
| 453 of one or more libraries, usually related to each other in some way, | |
| 454 bundled with administrative information for convenient distribution. | |
| 455 | |
| 456 @subsection Package Flavors | |
| 457 | |
| 458 There are two main flavors of packages. | |
| 459 | |
| 460 @table @strong | |
| 461 @item Regular Packages | |
| 462 @cindex regular package | |
| 463 A regular package is a set of Lisp libraries design to cooperate with | |
| 464 one another. A very complex example is Gnus. One may not in general | |
| 465 safely remove any of the component libraries. | |
| 466 | |
| 467 @item Single-File Packages | |
| 468 @cindex single-file package | |
| 901 | 469 A single-file package is a collection of thematically related but |
| 693 | 470 otherwise independent Lisp libraries. These libraries are bundled |
| 471 together for convenience of the maintainers. Usually individual | |
| 472 libraries may be deleted at will without any loss of functionality of | |
| 473 other libraries in the package. However, we would recommend that you | |
| 474 follow this rule of thumb: "When in doubt, don't delete". If it's | |
| 475 really that big a deal, request that the maintainers split the package | |
| 476 into smaller aggregations. | |
| 477 @end table | |
| 478 | |
| 479 @subsection Package Distributions | |
| 480 @cindex package distributions | |
| 481 @cindex binary packages | |
| 482 @cindex source packages | |
| 483 XEmacs Lisp packages are distributed in two ways. @dfn{Binary packages} | |
| 484 are used by system administrators and end users. They are packaged in a | |
| 485 form convenient for direct installation into an XEmacs package | |
| 486 hierarchy. @dfn{Source packages} are for developers and include all | |
| 487 files necessary for rebuilding byte-compiled lisp and creating tarballs | |
| 488 for distribution or installation. This is all of the package author's | |
| 489 source code plus all of the files necessary to build distribution | |
| 490 tarballs (Unix Tar format files, gzipped for space savings). | |
| 1648 | 491 (Occasionally sources that are not relevant to XEmacs are usually |
| 492 renamed to @file{file.upstream}.) | |
| 693 | 493 |
| 494 Currently, source packages are only available via CVS. See | |
| 495 @url{http://www.xemacs.org/Develop/cvsaccess.html} for details. | |
| 496 | |
| 497 The package distributions are also split according to major features | |
| 498 required in XEmacs to support them. At present there are @dfn{generic} | |
| 499 packages, which can be loaded by @emph{any} XEmacs, and @dfn{Mule} | |
| 500 packages, which @emph{require} Mule support or they will cause errors | |
| 501 when loaded. Note that there is no guarantee that a generic package | |
| 502 will have any useful functionality in a minimally configured XEmacs. As | |
| 503 long as any XEmacs can successfully load the package's libraries | |
| 504 (perhaps given other required Lisp libraries), it will be classified as | |
| 505 generic. At the present time only Mule packages need be treated | |
| 506 specially, and even those only if they contain multibyte characters. | |
| 507 | |
| 508 | |
| 1648 | 509 @node Building Packages, Makefile Targets, Package Terminology, Packaging |
| 693 | 510 @comment node-name, next, previous, up |
| 511 @cindex building packages | |
| 512 @cindex package building | |
| 513 @heading Building Packages: | |
| 514 Currently, source packages are only available via anonymous CVS. See | |
| 515 @url{http://www.xemacs.org/Develop/cvsaccess.html} for details of | |
| 516 checking out the @file{packages} module. | |
| 517 | |
| 518 @subsection Prerequisites for Building Source Packages | |
| 519 | |
| 520 @table @code | |
| 521 @item GNU cp | |
| 522 @item GNU install | |
| 523 (or a BSD compatible install program). | |
| 524 @item GNU make | |
| 1648 | 525 (3.79 or later preferred). |
| 693 | 526 @item makeinfo |
|
5744
9c17f7be0b92
Require makeinfo 4.12 or later to build the info files. See xemacs-beta
Jerry James <james@xemacs.org>
parents:
5741
diff
changeset
|
527 (4.12 from texinfo-4.12) |
| 693 | 528 @item GNU tar |
| 529 (or equivalent). | |
| 530 @item GNU gzip | |
| 531 (or equivalent). | |
| 532 @item A properly configured @file{Local.rules} file. | |
| 533 @ref{Local.rules File}. | |
| 534 @end table | |
| 535 | |
| 536 And of course, XEmacs, 21.0 or higher. | |
| 537 | |
| 1648 | 538 @section What You Can Do With Source Packages |
| 693 | 539 |
| 540 The packages CVS sources are most useful for creating XEmacs package | |
| 541 tarballs for installation into your own XEmacs installations or for | |
| 542 distributing to others. | |
| 543 | |
| 1648 | 544 It should be noted that most of the package @file{Makefile}s do |
| 545 @emph{not} need to contain @emph{any} target rules. Everything is | |
| 546 handled from the @file{XEmacs.rules} file, located in the toplevel | |
| 547 directory of the packages source tree. | |
| 548 | |
| 549 | |
| 550 @node Makefile Targets, Local.rules File, Building Packages, Packaging | |
| 551 @cindex package makefile targets | |
| 552 @chapter @file{Makefile} targets | |
| 553 The following targets can be used when running @code{make} to build the | |
| 554 packages: | |
| 555 | |
| 556 @table @samp | |
| 557 @item mostlyclean | |
| 558 Removes any documentation files that have been processed by @TeX{}. | |
| 693 | 559 |
| 1648 | 560 @item clean |
| 561 Does a @code{mostlyclean}, plus removes generated postscript and dvi | |
| 562 files. Also removes any generated .elc files, along with the normal | |
| 563 .elc files in the package and HTML and .info files. | |
| 564 | |
| 565 @item distclean | |
| 566 Use this when preparing a distribution. It kills anything that can be | |
| 567 rebuilt. | |
| 693 | 568 |
| 1648 | 569 @item extraclean |
| 570 Does a @code{distclean} and also removes any backup files (@file{*~}) | |
| 571 and @file{core} files. | |
| 572 | |
| 573 @item package-info | |
| 574 Creates the @file{package-info} file from the @file{package-info.in} and | |
| 575 writes an entry in the @file{package-index} file. | |
| 576 | |
| 693 | 577 @item bindist |
| 1648 | 578 Builds the package, including any Texinfo documentation (info format), |
| 579 writes an entry into the @file{package-index} file and builds a tarball | |
| 580 of the package. Also writes an entry into @file{setup-packages.ini} | |
| 581 which is later used in the creation of netinstaller's @file{setup.ini}. | |
| 693 | 582 |
| 583 @item install | |
| 1648 | 584 Builds and installs a package |
| 693 | 585 |
| 1648 | 586 @item install-only |
| 587 Doesn't build anything, just installs it. | |
| 588 | |
| 589 @item autoloads | |
| 590 Generate the package's @file{auto-autoloads.el} file. | |
| 693 | 591 |
| 592 @item binkit | |
| 1648 | 593 Creates the directories needed for installation and copies the files |
| 594 there. Basically this is an alias for @code{install-only}. | |
| 693 | 595 |
| 1648 | 596 @item html |
| 597 Builds the HTML versions of the documentation. | |
| 693 | 598 |
| 1648 | 599 @item compile |
| 600 Does most of the work. Builds the elcs, infos at a minimum. | |
| 693 | 601 @end table |
| 602 | |
|
5741
d11efddf3617
Fix texinfo constructs that are rejected by texinfo 5.x. See xemacs-patches
Jerry James <james@xemacs.org>
parents:
5402
diff
changeset
|
603 @section The targets that most people would be interested in would be: |
| 1648 | 604 |
| 605 @itemize @bullet | |
| 606 @item @code{all} | |
| 607 @item @code{bindist} | |
| 608 @item @code{html} | |
| 609 @item @code{install} | |
| 610 @item @code{install-only} | |
| 611 @item @code{clean} | |
| 612 @item @code{distclean} | |
| 613 @end itemize | |
| 614 | |
| 615 | |
| 616 @node Local.rules File, Creating Packages, Makefile Targets, Packaging | |
| 693 | 617 @comment node-name, next, previous, up |
| 618 @cindex local.rules | |
| 619 @heading The Local.rules File: | |
| 2955 | 620 This file in @file{packages} provides the @value{xpms} with information about |
| 693 | 621 the local configuration and environment. To create @file{Local.rules}, |
| 622 simply copy @file{Local.rules.template} from that directory to | |
| 623 @file{Local.rules} and edit it to suit your needs. | |
| 624 | |
| 1648 | 625 These are the variables in @file{Local.rules} that you may need to |
| 626 provide values for: | |
| 693 | 627 |
| 1648 | 628 @table @samp |
| 629 @item XEMACS | |
| 630 The name (and path if needed) of the XEmacs binary to use for building | |
| 631 the packages. The default is @code{xemacs}. | |
| 693 | 632 |
| 1648 | 633 @item XEMACS_21_5 |
| 634 This will enable some, as yet, unimplemented features in XEmacs 21.5 and | |
| 635 above. For now leave this blank (the default) regardless of the XEmacs | |
| 636 version you are using. | |
| 693 | 637 |
| 638 @item BUILD_WITHOUT_MULE | |
| 1648 | 639 Set this to @samp{t} if you are using a non-Mule XEmacs. The default is |
| 640 that this variable is not set (blank) which means to build @emph{with} | |
| 641 Mule. | |
| 642 | |
| 643 @item XEMACS_NATIVE_NT | |
| 644 Set this to @samp{t} if you are using a native Microsoft Windows build | |
| 645 of XEmacs (not a Cygwin build) to build the packages. | |
| 646 @strong{N.B.} To Windows users, you still need the Cygwin environment to | |
| 647 actually build the packages. | |
| 648 | |
| 649 @item XEMACS_INSTALLED_PACKAGES_ROOT | |
| 650 Set this to the root of where you want the packages to be installed. | |
| 651 Under this directory will hang @file{xemacs-packages} and | |
| 1738 | 652 @file{mule-packages}. See @code{NONMULE_INSTALLED_PACKAGES_ROOT} and |
| 653 @code{MULE_INSTALLED_PACKAGES_ROOT}. The default for this is | |
| 1648 | 654 @file{/usr/local/lib/xemacs}. Which may not be what you want if you are |
| 655 developing XEmacs. To quote the comments in | |
| 1738 | 656 @file{Local.rules.template}: |
| 1648 | 657 |
| 658 @quotation | |
| 659 If you are developing XEmacs, you probably don't want to install the | |
| 660 packages under /usr/local, which is where the stable, released version | |
| 661 of XEmacs goes. Instead, we suggest a layout as described in the base | |
| 662 README file of recent versions of XEmacs. In a nutshell, we suggest | |
| 663 you put your source under /src/xemacs, and under this put the package | |
| 664 sources in package-src/, and the installed packages in xemacs-packages/ | |
| 665 and mule-packages/. If you do everything this way, you might want to | |
| 666 set things as follows: | |
| 667 | |
| 668 XEMACS_INSTALLED_PACKAGES_ROOT = $@{XEMACS_PACKAGES_BASE@}/.. | |
| 693 | 669 |
| 1648 | 670 which puts the xemacs-packages/ and mule-packages/ directories as sisters |
| 671 of the package-src/ directory, and you have to tell configure the location | |
| 672 of the installed packages using `--package-path', something like | |
| 673 | |
| 674 configure --package-path=/src/xemacs/xemacs-packages;/src/xemacs/mule-packages | |
| 675 @end quotation | |
| 676 | |
| 677 @item symlink | |
| 678 The default is unset (blank). If you set this to @samp{t} then | |
| 679 @code{make install} will create a @dfn{symlink farm} of the installed | |
| 1738 | 680 packages under @code{XEMACS_INSTALLED_PACKAGES_ROOT}. Obviously, for |
| 1648 | 681 this to work, your system has to support symbolic links. This is as |
| 682 close as you can get to @dfn{running in place} for the packages. | |
| 683 | |
| 684 @item NONMULE_INSTALLED_PACKAGES_ROOT | |
| 685 This is where the non-Mule packages get installed to. The default is | |
| 686 @file{$@{XEMACS_INSTALLED_PACKAGES_ROOT@}/xemacs-packages}. | |
| 687 | |
| 688 @item MULE_INSTALLED_PACKAGES_ROOT | |
| 689 This is where the Mule packages get installed to. The default is | |
| 690 @file{$@{XEMACS_INSTALLED_PACKAGES_ROOT@}/mule-packages}. | |
| 691 | |
| 692 @item NONMULE_PACKAGES | |
| 693 A whitespace separated list of non-Mule packages to build/install. | |
| 694 | |
| 695 @example | |
| 696 NONMULE_PACKAGES = bbdb gnus xemacs-base prog-modes | |
| 697 @end example | |
| 698 | |
| 699 The value for this variable can also be the symbol | |
| 700 @samp{xemacs-packages}, which means to build/install @emph{all} of the | |
| 701 non-Mule packages. The default is @samp{xemacs-packages}. | |
| 693 | 702 |
| 703 @item MULE_PACKAGES | |
| 1648 | 704 A whitespace separated list of Mule packages to build/install. |
| 705 | |
| 706 @example | |
| 707 MULE_PACKAGES = mule-base leim locale | |
| 708 @end example | |
| 709 | |
| 710 The value for this variable can also be the symbol | |
| 711 @samp{mule-packages}, which means to build/install @emph{all} of the | |
| 712 Mule packages. The default is @samp{mule-packages}. | |
| 713 | |
| 714 @item PACKAGE_INDEX | |
| 715 The name of the package-index file. The default is @file{package-index} | |
| 716 and you probably don't need to worry about changing it. | |
| 693 | 717 |
| 1648 | 718 @item INSTALL |
| 719 The path to a BSD compatible install program. The default is | |
| 720 @code{install -c}. | |
| 721 | |
| 722 @item TAR | |
| 723 The path to GNU/tar. The default is @code{tar}. | |
| 724 | |
| 725 @item BZIP2 | |
| 726 The path to the bzip2 compression program. The default is unset | |
| 727 (blank). If this is set @file{.tar.bz2} archives will be built | |
| 728 @emph{in addition to} the @file{.tar.gz} archives. | |
| 729 | |
| 730 @item EXCLUDES | |
| 731 For things that you @emph{don't} want to go into the package tarballs. | |
| 732 It takes the same format as GNU/tar's @code{--exclude} option. The | |
| 733 default is: | |
| 693 | 734 |
| 735 @example | |
| 1648 | 736 EXCLUDES = \ |
| 737 --exclude 'CVS' \ | |
| 738 --exclude 'RCS' \ | |
| 739 --exclude 'SCCS' \ | |
| 740 --exclude '*~' \ | |
| 741 --exclude '*.orig' \ | |
| 742 --exclude '*.rej' \ | |
| 743 --exclude '.\#*' | |
| 744 @end example | |
| 745 | |
| 746 @item VANILLA | |
| 747 Set to the XEmacs command line option that forces running in | |
| 748 @dfn{vanilla} mode. The default is @samp{-vanilla}. You wouldn't ever | |
| 749 need to alter this. | |
| 750 | |
| 751 @item BATCH | |
| 752 How to put XEmacs into @dfn{batch} mode. It also sets a couple of other | |
| 753 things and in the normal course of events you wouldn't need to alter | |
| 754 this from the default which is: | |
| 755 | |
| 756 @example | |
| 757 BATCH = $(VANILLA) -batch -eval \ | |
| 758 '(setq stack-trace-on-error t \ | |
| 759 load-always-display-messages t \ | |
| 760 load-ignore-out-of-date-elc-files t \ | |
| 761 load-show-full-path-in-messages t)' | |
| 693 | 762 @end example |
| 763 | |
| 1648 | 764 @item MAKEINFO |
| 765 The path to @code{makeinfo}. The default is @samp{makeinfo} | |
| 766 | |
| 767 @item INSTALL_HTML | |
| 768 Set this to @samp{t} if you want to install HTML versions of the Texinfo | |
| 769 documentation. The default is unset (blank). | |
| 770 | |
| 771 @item TEXI2HTML | |
| 772 The path to the program that can convert Texinfo source to HTML. The | |
| 773 default is @code{texi2html}. | |
| 774 | |
| 775 @item TEXI2DVI | |
| 776 The path to the program that can convert Texinfo source to DVI. The | |
| 777 default is @code{texi2dvi} | |
| 693 | 778 |
| 1648 | 779 @item DVIPS |
| 780 The path to the program that can convert DVI to Postscript. The default | |
| 781 is @code{dvips} | |
| 782 | |
| 783 @item TEXI2PDF | |
| 784 The path to the program that can convert Texinfo source to PDF format. | |
| 785 The default is @code{texi2pdf}. | |
| 786 | |
| 787 @item TEX | |
| 788 The path to @TeX{}. The default is @code{tex} | |
| 789 | |
| 790 @item MSGFMT | |
| 791 The path to msgfmt. The default is @code{msgfmt} | |
| 792 | |
| 793 @item RCOPY | |
| 794 The path to your copy command (GNU cp). The default is dependent on | |
| 795 whether or not @var{symlink} is set (@samp{t}). | |
| 796 | |
| 1738 | 797 If @var{symlink} is unset (blank), @code{RCOPY}'s default is |
| 798 @code{cp -af}. If @var{symlink} is set (@samp{t}), @code{RCOPY}'s | |
| 1648 | 799 default is @code{cp --force --recursive --symbolic-link}. |
| 693 | 800 @end table |
| 801 | |
| 1648 | 802 It should be noted that in most cases the defaults should be fine. Most |
| 803 people will probably only need to alter: | |
| 693 | 804 |
| 1648 | 805 @itemize @bullet |
| 1738 | 806 @item @code{XEMACS_INSTALLED_PACKAGES_ROOT} |
| 807 @item @code{NONMULE_INSTALLED_PACKAGES_ROOT} | |
| 808 @item @code{MULE_INSTALLED_PACKAGES_ROOT} | |
| 809 @item @code{NONMULE_PACKAGES} | |
| 810 @item @code{MULE_PACKAGES} | |
| 1648 | 811 @end itemize |
| 693 | 812 |
| 752 | 813 @node Creating Packages, Documenting Packages, Local.rules File, Packaging |
| 693 | 814 @comment node-name, next, previous, up |
| 815 @cindex creating packages | |
| 1648 | 816 @chapter Creating Packages: |
| 693 | 817 Creating a package from an existing Lisp library is not very difficult. |
| 818 | |
| 819 In addition to the Lisp libraries themselves, you need a | |
| 1648 | 820 @ref{package-info.in} file and a simple @ref{Makefile}. The rest is |
| 693 | 821 done by @file{XEmacs.rules}, part of the packaging system |
| 822 infrastructure. | |
| 823 | |
| 1648 | 824 @menu |
| 825 * package-info.in:: package-info.in | |
| 826 * Makefile:: @file{Makefile} | |
| 827 @end menu | |
| 828 | |
| 829 @node package-info.in, Makefile,,Creating Packages | |
| 830 @chapter package-info.in | |
| 831 @cindex package-info.in | |
| 832 @cindex package-info | |
| 833 @file{package-info.in} contains information that gets injected into the | |
| 834 @file{package-index} file when @code{make bindist} is run. Here is a | |
| 835 real world example from the xemacs-base package (a description of each | |
| 836 field follows the example): | |
| 693 | 837 |
| 838 @example | |
| 1648 | 839 (xemacs-base |
| 693 | 840 (standards-version 1.1 |
| 1648 | 841 version VERSION |
| 842 author-version AUTHOR_VERSION | |
| 843 date DATE | |
| 844 build-date BUILD_DATE | |
| 845 maintainer MAINTAINER | |
| 846 distribution xemacs | |
| 693 | 847 priority high |
| 1648 | 848 category CATEGORY |
| 693 | 849 dump nil |
| 1648 | 850 description "Fundamental XEmacs support, you almost certainly need this." |
| 851 filename FILENAME | |
| 852 md5sum MD5SUM | |
| 853 size SIZE | |
| 854 provides (add-log advice-preload advice annotations assoc case-table chistory comint-xemacs comint compile debug ebuff-menu echistory edmacro ehelp electric enriched env facemenu ffap helper imenu iso-syntax macros novice outline passwd pp regexp-opt regi ring shell skeleton sort thing time-stamp timezone tq xbm-button xpm-button) | |
| 855 requires (REQUIRES) | |
| 693 | 856 type regular |
| 857 )) | |
| 858 @end example | |
| 859 | |
| 1648 | 860 @subheading Description of the Fields in @file{package-info.in}: |
| 861 @table @samp | |
| 862 @item NAME | |
| 863 The name of the package. In the case of the example it is | |
| 864 @samp{xemacs-base}. | |
| 865 | |
| 866 @item standards-version | |
| 867 Part of the internal package infrastructure, its value should always be | |
| 868 @samp{1.1}. Do not change this. | |
| 869 | |
| 870 @item version | |
| 871 This is the XEmacs package version number of the package. It is set | |
| 1738 | 872 from the @file{Makefile} variable @code{VERSION}. This is something |
| 873 that the XEmacs Package Release Engineer deals with so there is no need | |
| 874 for a package maintainer to touch it. In @file{package-info.in} just | |
| 875 put the place-marker, @samp{VERSION} here. | |
| 1648 | 876 |
| 877 @item author-version | |
| 878 This is the package's internal, or @samp{upstream} version number if it | |
| 879 has one. It is set from the @file{Makefile} variable | |
| 1738 | 880 @code{AUTHOR_VERSION}. |
| 1648 | 881 |
| 882 @item date | |
| 883 This is the date of the last change made to the package. It is | |
| 884 auto-generated at build time, taken from the package's toplevel | |
| 885 @file{ChangeLog}. | |
| 886 | |
| 887 @item build-date | |
| 888 The date the package was built. It is auto-generated. | |
| 889 | |
| 890 @item maintainer | |
| 891 This is the name and email address of the package's maintainer. It is | |
| 1738 | 892 taken from the @file{Makefile} variable @code{MAINTAINER}. |
| 1648 | 893 |
| 894 @item distribution | |
| 895 An unused field, leave as @samp{xemacs} | |
| 896 | |
| 897 @item priority | |
| 898 An unused field, can be any of @samp{high}, @samp{medium}, or | |
| 899 @samp{low}. | |
| 900 | |
| 901 @item category | |
| 902 The @samp{category} of the package. It is taken from the | |
| 1738 | 903 @file{Makefile} variable @code{CATEGORY} and can be either |
| 1648 | 904 @samp{standard} for non-Mule packages, or @samp{mule} for Mule |
| 905 packages. The is also provision for @samp{unsupported} in this field | |
| 906 which would be for packages that XEmacs.org do not distribute. | |
| 907 | |
| 2955 | 908 @strong{N.B.} As yet, the @value{xpms} does @emph{not} support this type of |
| 1648 | 909 package. It will in the future. |
| 910 | |
| 911 @item dump | |
| 912 Unused. Always @samp{nil} | |
| 913 | |
| 914 @item description | |
| 915 A free form short description of the package. | |
| 693 | 916 |
| 1648 | 917 @item filename |
| 918 The file name of the package's binary tarball. It is generated at build | |
| 919 time by @code{make bindist}. | |
| 920 | |
| 921 @item md5sum | |
| 922 The MD5 message digest of the package's binary tarball. Generated at | |
| 923 build time by @code{make bindist}. | |
| 924 | |
| 925 @item size | |
| 926 The size in bytes of the package's binary tarball. Generated at build | |
| 927 time. | |
| 928 | |
| 929 @item provides | |
| 930 A whitespace separated list of @emph{all} the features the package | |
| 931 provides. Surround the list with parens. | |
| 932 | |
| 933 @item requires | |
| 1738 | 934 Taken from the @file{Makefile} variable @code{REQUIRES}. It is a list |
| 935 of all the package's dependencies, including any macros and defstructs | |
| 936 that need to be inlined. | |
| 693 | 937 |
| 1648 | 938 @samp{REQUIRES} cannot be correctly computed from the calls to |
| 939 @code{require} in the package's library sources. @samp{REQUIRES} is | |
| 940 used to ensure that all macro and defstruct definitions used by the | |
| 941 package are available at build time. This is not merely a matter of | |
| 942 efficiency, to get the expansions inlined. In fact, it is | |
| 943 @emph{impossible} to call a macro by name in byte-compiled Emacs Lisp | |
| 944 code. Thus, if the macro expansion is not inlined, the call will result | |
| 945 in an error at run-time! Thus, packages providing libraries that would | |
| 946 be loaded because of autoload definitions must also be included. | |
| 947 | |
| 948 @item type | |
| 949 Can either be @samp{regular} for a regular package, or | |
| 950 @samp{single-file} for a single file package. | |
| 951 | |
| 952 @strong{N.B.} This doesn't refer to the number of lisp files in a | |
| 953 package. A single-file package can have multiple lisp files in it. | |
| 954 @xref{Package Terminology}. | |
| 955 @end table | |
| 956 | |
| 957 The fields in @file{package-info.in} that need to be changed directly | |
| 958 are: | |
| 959 | |
| 960 @itemize @bullet | |
| 961 @item NAME | |
| 962 @item description | |
| 963 @item provides | |
| 964 @item type | |
| 965 @end itemize | |
| 966 | |
| 967 Everything else is either set from the appropriate @file{Makefile} | |
| 968 variable, is auto-generated at build time, or is static. | |
| 969 | |
| 970 @node Makefile,,package-info.in,Creating Packages | |
| 971 @chapter @file{Makefile} | |
| 972 @cindex Makefile, package | |
| 973 @cindex package Makefile | |
| 693 | 974 The @file{Makefile} is quite stylized. The idea is similar to an |
| 975 @file{Imakefile} or an @code{automake} file: the complexity is hidden in | |
| 976 generic rules files, in this case the @file{XEmacs.rules} include file | |
| 977 in the top directory of the packages hierarchy. | |
| 978 | |
| 1648 | 979 It is important to note that the XEmacs used to compile packages is |
| 980 the bare minimum: it is called with the @samp{-no-autoloads}. This | |
| 981 means that anything not dumped into XEmacs by default needs to be | |
| 982 specified in the @samp{REQUIRES} variable (for packaged Lisp) or in | |
| 983 some cases the @samp{PRELOADS} (autoloads used in libraries mentioned | |
| 984 in @samp{PRELOADS}). | |
| 749 | 985 |
| 2955 | 986 There isn't much to an @value{xpms} @file{Makefile}, basically it just |
| 1648 | 987 contains a few @file{Makefile} variables and that's it. See the |
| 988 example. | |
| 693 | 989 |
| 1648 | 990 Here is a real world example, from the @samp{build} package: |
| 693 | 991 |
| 992 @example | |
| 1648 | 993 # Makefile for build lisp code |
| 693 | 994 |
| 995 # This file is part of XEmacs. | |
|
5402
308d34e9f07d
Changed bulk of GPLv2 or later files identified by script
Mats Lidell <matsl@xemacs.org>
parents:
3179
diff
changeset
|
996 # |
|
308d34e9f07d
Changed bulk of GPLv2 or later files identified by script
Mats Lidell <matsl@xemacs.org>
parents:
3179
diff
changeset
|
997 # XEmacs is free software: you can redistribute it and/or modify it |
| 693 | 998 # under the terms of the GNU General Public License as published by the |
|
5402
308d34e9f07d
Changed bulk of GPLv2 or later files identified by script
Mats Lidell <matsl@xemacs.org>
parents:
3179
diff
changeset
|
999 # Free Software Foundation, either version 3 of the License, or (at your |
|
308d34e9f07d
Changed bulk of GPLv2 or later files identified by script
Mats Lidell <matsl@xemacs.org>
parents:
3179
diff
changeset
|
1000 # option) any later version. |
|
308d34e9f07d
Changed bulk of GPLv2 or later files identified by script
Mats Lidell <matsl@xemacs.org>
parents:
3179
diff
changeset
|
1001 # |
| 693 | 1002 # XEmacs is distributed in the hope that it will be useful, but WITHOUT |
| 1003 # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | |
| 1004 # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License | |
| 1005 # for more details. | |
|
5402
308d34e9f07d
Changed bulk of GPLv2 or later files identified by script
Mats Lidell <matsl@xemacs.org>
parents:
3179
diff
changeset
|
1006 # |
| 693 | 1007 # You should have received a copy of the GNU General Public License |
|
5402
308d34e9f07d
Changed bulk of GPLv2 or later files identified by script
Mats Lidell <matsl@xemacs.org>
parents:
3179
diff
changeset
|
1008 # along with XEmacs. If not, see <http://www.gnu.org/licenses/>. |
| 693 | 1009 |
| 1648 | 1010 # For the time being, remove MULE_ELCS from the all dependencies if |
| 1011 # building without Mule. | |
| 1012 | |
| 1013 VERSION = 1.10 | |
| 1014 AUTHOR_VERSION = 2.02 | |
| 1015 MAINTAINER = Adrian Aichner <adrian@@xemacs.org> | |
| 1016 PACKAGE = build | |
| 693 | 1017 PKG_TYPE = regular |
| 1648 | 1018 REQUIRES = xemacs-base pcl-cvs dired w3 prog-modes |
| 693 | 1019 CATEGORY = standard |
| 1020 | |
| 1648 | 1021 ELCS = build.elc build-report.elc |
| 1022 | |
| 1023 STANDARD_DOCS = t | |
| 693 | 1024 |
| 1025 include ../../XEmacs.rules | |
| 1648 | 1026 @end example |
| 693 | 1027 |
| 1648 | 1028 Most packages don't need any more than what you see above. It is |
| 1029 usually @emph{not} necessary to specify any special @file{Makefile} | |
| 1030 rules. Everything is handled from the @file{*.rules} files in the | |
| 1031 toplevel of the package source hierarchy. | |
| 1032 | |
| 1033 Of course, with that said, there are always exceptions to the rule. If | |
| 1034 you think that your package will need some special @file{Makefile} | |
| 1035 hackery contact the @email{xemacs-beta@@xemacs.org, XEmacs developers}. | |
| 1036 We distribute over 100 packages so the chances are good that you won't | |
| 1037 be the first to need such hackery and it is probably already catered | |
| 1038 for. | |
| 1039 | |
| 1040 @subheading @file{Makefile} Variables Explained: | |
| 2955 | 1041 A number of @file{make} variables are defined by the @value{xpms}. Some are |
| 1648 | 1042 required, others are optional. Of course your @file{Makefile} may |
| 1043 define other variables for private use, but you should be careful not to | |
| 1044 choose names that conflict with variables defined and used by the | |
| 2955 | 1045 @value{xpms}. |
| 1648 | 1046 |
| 1047 The required variables are described in the table below. | |
| 1048 The corresponding field names for @file{package-info.in}, where | |
| 1049 relevant, are given in parentheses. | |
| 1050 | |
| 1051 @c This is the canonical place for this information. If there is | |
| 1052 @c unnecessary duplication with package-info.in documentation, shorten | |
| 1053 @c that and leave this full-length. | |
| 1054 @table @samp | |
| 1055 @item VERSION | |
| 1056 (version) | |
| 1057 The version of the XEmacs package, a numeric literal (a decimal | |
| 1058 fixed-point number with two-places of precision). The only person who | |
| 1059 ever needs to touch this is the XEmacs Packages Release Engineer. | |
| 1060 | |
| 1061 @item AUTHOR_VERSION | |
| 1062 (author-version) | |
| 1063 The upstream author's version, an uninterpreted literal. | |
| 1064 | |
| 1065 @item MAINTAINER | |
| 1066 (maintainer) | |
| 1067 A literal containing the XEmacs package's maintainer and his/her email | |
| 1068 address. | |
| 1069 | |
| 1070 @item PACKAGE | |
| 1071 The name of the package, a literal | |
| 1072 | |
| 1073 @item PKG_TYPE | |
| 1074 The type of package, a literal containing either @samp{regular} for | |
| 1075 regular packages, or @samp{single-file} for single-file packages. This | |
| 1076 should feed the @samp{type} field in @file{package-info.in}, but | |
| 1077 currently it doesn't. | |
| 1078 | |
| 1079 @strong{N.B.} @samp{single-file} here does @emph{not} refer to the | |
| 1080 number of lisp files in a package. @xref{Package Terminology}. | |
| 693 | 1081 |
| 1648 | 1082 @item CATEGORY |
| 1083 (category) | |
| 1084 A literal, either @samp{standard} or @samp{mule}. The non-Mule packages | |
| 1085 are @samp{standard} and the Mule packages are, you guessed it, | |
| 1086 @samp{mule}. This field is used at package installation time as part of | |
| 1087 the process of determining where a package should be installed to. | |
| 1088 | |
| 1089 @item REQUIRES | |
| 1090 (requires) | |
| 1091 A list of packages required to correctly build this package. | |
| 1092 | |
| 1093 Note that the usual form in @file{package-info.in} already has the | |
| 1094 parentheses, so the @file{make} variable should be set to a | |
| 1095 space-separated list of package names @emph{not} enclosed in | |
| 1096 parentheses. | |
| 1097 | |
| 1098 The list is of @emph{packages}, not @emph{libraries}, as would | |
| 1099 ordinarily be provided to the Lisp @code{require} function. | |
| 1100 | |
| 1101 @samp{REQUIRES} cannot be correctly computed from the calls to | |
| 1102 @code{require} in the package's library sources. @samp{REQUIRES} is | |
| 1103 used to ensure that all macro and defstruct definitions used by the | |
| 1104 package are available at build time. This is not merely a matter of | |
| 1105 efficiency, to get the expansions inlined. In fact, it is | |
| 1106 @emph{impossible} to call a macro by name in byte-compiled Emacs Lisp | |
| 1107 code. Thus, if the macro expansion is not inlined, the call will result | |
| 1108 in an error at run-time! Thus, packages providing libraries that would | |
| 1109 be loaded because of autoload definitions must also be included. | |
| 693 | 1110 |
| 1648 | 1111 @item ELCS |
| 1112 The list of the byte-compiled Lisp files used by the package. These | |
| 1113 files and their @file{.el} versions will be included in the binary | |
| 1114 package. This variable determines which libraries will be | |
| 1115 byte-compiled. These libraries are also deleted by @samp{make clean}. | |
| 1116 | |
| 1117 Note there is no sanity-checking done on this variable. If you put | |
| 1118 @samp{.el} files in here, they will not be compiled and they @emph{will} | |
| 1119 be deleted by @samp{make clean}. You would surely be very distressed if | |
| 1120 that happened, so be very careful. If this variable is left empty, none | |
| 1121 of your Lisp code will be compiled or packaged. This would be a less | |
| 1122 than amusing surprise, too. | |
| 1123 | |
| 1124 We don't consider this a feature, of course. Please do submit code to | |
| 1125 do sanity checking to @email{xemacs-patches@@xemacs.org}. | |
| 1126 @end table | |
| 1127 | |
| 1128 Optional, but commonly used variables are explained below. | |
| 1129 | |
| 1130 @table @samp | |
| 1131 @item ELCS_1 | |
| 1132 A list of extra byte-compiled Lisp files used by the package to be | |
| 1133 installed in a subdirectory of the package's lisp directory. The same | |
| 1738 | 1134 care should be taken with this as with @code{ELCS} in regard to |
| 1648 | 1135 @code{make clean}. |
| 1136 | |
| 1137 @item ELCS_1_DEST | |
| 1738 | 1138 The name of the subdirectory for the @code{ELCS_1} files to be installed |
| 1648 | 1139 to. Be sure to include @samp{$(PACKAGE)/} as part of the name. |
| 1140 | |
| 1141 @example | |
| 1142 ELCS_1_DEST = $(PACKAGE)/extra | |
| 693 | 1143 @end example |
| 1144 | |
| 1738 | 1145 Would put the @code{ELCS_1} files for the package, @samp{foo} into |
| 1146 @file{xemacs-packages/lisp/foo/extra/}. | |
| 1648 | 1147 |
| 1148 @item EARLY_GENERATED_LISP | |
| 1149 For additional @file{.el} files that will be generated before any | |
| 1150 byte-compiling happens. Use this for @samp{autoload-type} files. You | |
| 1151 must write @file{Makefile} rules to build these files. | |
| 1152 | |
| 1153 @item GENERATED_LISP | |
| 1154 For additional @file{.el} files that will be generated at | |
| 1155 byte-compilation time. You must write @file{Makefile} rules to build | |
| 1156 these files. | |
| 1157 | |
| 1158 @item PRELOADS | |
| 1159 This is used if you need to pass extra command line arguments to | |
| 1160 XEmacs to build the package. For instance, a specification for | |
| 1161 loading libraries containing macros before compiling the Lisp in the | |
| 1162 package. This is spliced directly into the invocation of XEmacs for | |
| 1163 byte-compilation, so it must contain the @samp{-l} flag for XEmacs: | |
| 1164 | |
| 1165 @example | |
| 1166 PRELOADS=-l ./apackage-macros.el -l ../bpackage/lisp/bpackage-macros.el | |
| 1167 @end example | |
| 1168 | |
| 1169 Preloads are loaded before @file{package-compile.el}, so the | |
| 1738 | 1170 @code{load-path} is minimal. Therefore @samp{PRELOADS} must specify a |
| 1171 full path to packaged Lisp. The base @code{load-path} does include the | |
| 1648 | 1172 core Lisp directory, so core libraries are found. |
| 1173 | |
| 1174 @item AUTOLOAD_PATH | |
| 1175 The subdirectory in the package's source tree where the @file{.el} files | |
| 1176 reside. This is where the @file{auto-autoloads.el} file will be placed. | |
| 1177 | |
| 1178 @strong{N.B.} There is no need to use this variable if the @file{.el} | |
| 1738 | 1179 files are in the package's toplevel directory. @code{AUTOLOAD_PATH} |
| 1648 | 1180 defaults to @samp{.}. |
| 1181 | |
| 1182 @item PACKAGE_SUPPRESS | |
| 1183 Place calls to @code{package-suppress} here to indicate Lisp libraries | |
| 1184 that should only be available to particular versions of XEmacs. For | |
| 1185 example: | |
| 1186 | |
| 1187 @example | |
| 1188 PACKAGE_SUPPRESS = \ | |
| 1189 (package-suppress 'xemacs-base \"regexp-opt\" '(emacs-version>= 21 5 11)) \ | |
| 1190 (package-suppress 'xemacs-base \"easy-mmode\" '(emacs-version>= 21 5 11)) | |
| 1191 @end example | |
| 1192 | |
| 1193 @c Change this when Ben has committed the WS that implements | |
| 1194 @c `package-suppress' --SY. | |
| 1195 @strong{N.B.} This feature has not yet been implemented in XEmacs yet. | |
| 1196 It will appear in an upcoming version of XEmacs 21.5. | |
| 1197 | |
| 1198 @item STANDARD_DOCS | |
| 1199 Set this to @samp{t} if your package's Texinfo source file is located in | |
| 1200 the package's toplevel directory @emph{and} is named | |
| 1201 @file{$(PACKAGE).texi}. | |
| 1202 | |
| 1203 @item EXPLICIT_DOCS | |
| 1204 Use this to explicitly list Texinfo sources that @emph{aren't} in the | |
| 1205 package's toplevel directory. For example: | |
| 1206 | |
| 1207 @example | |
| 1208 EXPLICIT_DOCS = texi/$(PACKAGE).texi | |
| 1209 @end example | |
| 693 | 1210 |
| 1738 | 1211 See @code{DOCS_TXI_EXTENSION} and @code{DOCS_TEXINFO_EXTENSION} if you |
| 1648 | 1212 don't use the @file{.texi} file extension on your Texinfo sources. |
| 693 | 1213 |
| 1648 | 1214 @item EXTRA_TEXI_FILES |
| 1215 List here extra Texinfo source files needed to build your | |
| 1216 documentation. Whatever is listed here is passed on to @code{makeinfo} | |
| 1217 as a dependency. | |
| 1218 | |
| 1219 @item EXTRA_HTML_FILES | |
| 1220 Use this to specify extra @file{.html} files to output. | |
| 1221 | |
| 1222 @item DOCS_TEXINFO_EXTENSION | |
| 1223 Set this to @samp{t} if your Texinfo source files have a @samp{.texinfo} | |
| 1224 extension. | |
| 1225 | |
| 1226 @item DOCS_TXI_EXTENSION | |
| 1227 Set this to @samp{t} if your Texinfo source files have a @samp{.txi} | |
| 1228 extension. | |
| 1229 | |
| 1230 @item EXTRA_DOC_FILES | |
| 1231 Files listed here will be installed to @file{.../man/$(PACKAGE)/}. For | |
| 1232 example, you might want to list @TeX{} files or @file{.eps} files here. | |
| 1233 | |
| 1234 @item EXTRA_SOURCES | |
| 1235 Other files (such as extra Lisp sources or an upstream @file{Makefile}) | |
| 1236 that are normally placed in the installed Lisp directory, but not | |
| 1237 byte-compiled. These files are @emph{preserved} by the @samp{clean} | |
| 1238 targets. | |
| 1239 | |
| 1240 @item LIBSRC_FILES | |
| 1241 For files that need to be installed to @file{lib-src/$(PACKAGE)/}. If | |
| 1242 the files listed here need to be built you will have to write | |
| 1243 @file{Makefile} rules to do so. | |
| 693 | 1244 |
| 1648 | 1245 @item DATA_FILES |
| 1246 Any data files, such as pixmaps, READMEs, and ChangeLogs. These must be | |
| 1247 paths relative to the root of the package's source tree. These files | |
| 1248 will be copied to @samp{$(DATA_DEST)} for installation. Any directory | |
| 1249 component of the path for a file will be stripped, so that the | |
| 1250 file ends up in @samp{$(DATA_DEST)}, not in a subdiredtory. | |
| 1251 | |
| 1252 @item DATA_DEST | |
| 1738 | 1253 The directory where the files in @code{DATA_FILES} are installed to. It |
| 1648 | 1254 is a subdirectory of the installed @file{etc/} directory. Be sure to |
| 1255 prefix this value with @samp{$(PACKAGE)}, for example: | |
| 1256 | |
| 1257 @example | |
| 1258 DATA_DEST = $(PACKAGE)/foo | |
| 1259 @end example | |
| 1260 | |
| 1261 Would put files into @file{.../etc/$(PACKAGE)/foo/}. | |
| 1262 | |
| 1263 @item DATA_1_FILES ... DATA_35_FILES | |
| 1264 For data files that need to go into a different directory from | |
| 1738 | 1265 @code{DATA_DEST}. |
| 1648 | 1266 |
| 1267 @item DATA_1_DEST ... DATA_35_DEST | |
| 1738 | 1268 The name of the subdirectory for files specified in |
| 1269 @code{DATA_@var{n}_FILES}. And like @code{DATA_DEST}, be sure to prefix | |
| 1270 @samp{$(PACKAGE)} to the value of these variables. | |
| 1648 | 1271 |
| 1272 @item EXTRA_DEPENDENCIES | |
| 1273 For additional files to build that aren't appropriate to place in any | |
| 1274 other @file{Makefile} variable. You will need to write @file{Makefile} | |
| 1275 rules to build these files. | |
| 1276 @end table | |
| 1277 | |
| 1278 @section @file{package-compile.el} | |
| 1279 @cindex package-compile.el | |
| 1280 @cindex compiling packages | |
| 2955 | 1281 The @value{xpms} does not automatically become aware of your package simply |
| 693 | 1282 because there is a new subtree. If any package, including your own, |
| 1283 requires any of your files, it must be explicitly added to the compile | |
| 1284 environment or loads/requires that search load-path will fail. The | |
| 1285 changes that need to be made are | |
| 1286 | |
| 1287 @table @strong | |
| 694 | 1288 @item an entry in @code{package-directory-map} |
| 2955 | 1289 This tells the @value{xpms} which distribution (currently |
| 693 | 1290 @samp{xemacs-packages} or @samp{mule-packages}) your package is found |
| 1291 in. It then looks in the distribution subdirectory whose name is the | |
| 1292 same as the package's. | |
| 1293 | |
| 1294 @item an entry in the @code{cond} in @code{package-name-to-directory} | |
| 1295 This is optional; it is necessary only if you keep your Lisp code | |
| 1296 somewhere other than the top-level directory of the package's source | |
| 1738 | 1297 tree, eg, in @file{packages/xemacs-packages/$(PACKAGE)/lisp}. |
| 693 | 1298 @end table |
| 1299 | |
| 1300 This only needs to be done once, when the package is first added to the | |
| 2955 | 1301 @value{xpms}. (Well, when you randomly change the subdirectory layout, too.) |
| 693 | 1302 Your changes to @file{package-compile.el} must be cleared and checked in |
| 1303 by the XEmacs Package Release Engineer before your package will build | |
| 1304 correctly from a fresh checkout. | |
| 1305 | |
| 694 | 1306 This is unfortunate; it works pretty well once set up, but can cause |
| 2955 | 1307 confusion when first building a package in the @value{xpms} context. In |
| 694 | 1308 particular, if the @code{package-directory-map} entry for a required |
| 1648 | 1309 package, including the package itself, is not found, the necessary |
| 1310 requires will not be executed by @file{package-compile.el}. If | |
| 1311 required functions are executed (under @code{eval-when-compile}), | |
| 1312 they won't be found and the compile will fail. If required function | |
| 1313 is actually a macro, the byte compiler will not recognize that, | |
| 1314 compile a function call to the macro. This will cause a run-time | |
| 1315 error because the byte-code interpreter does not know how to execute | |
| 1316 macros. (Macros can always be expanded at compile-time, and this is | |
| 1317 more efficient.) | |
| 694 | 1318 |
| 1319 If your package keeps some or all Lisp code somewhere other than the top | |
| 1320 directory, then an entry in @code{package-name-to-directory} is also | |
| 1321 necessary, or requires will fail, leading to the problems just described. | |
| 693 | 1322 |
| 752 | 1323 @node Documenting Packages, Issues, Creating Packages, Packaging |
| 1324 @comment node-name, next, previous, up | |
| 1325 @cindex documenting packages | |
| 1326 @heading Documenting Packages: | |
| 1327 | |
| 1328 @c #### Add a documentation section to Internals, and xref here. | |
| 1329 Some random notes on documenting your package. | |
| 1330 | |
| 1331 Do write a Texinfo file. It's not that hard to do basically, and even | |
| 1332 using the more advanced features of Texinfo soon become natural. For a | |
| 1333 start, just grab the template @file{Samples/package.texi} from the | |
| 2955 | 1334 @value{xpms} source tree, and drop your current README into the Top node. At |
| 752 | 1335 least this way your documentation will be accessible from the standard |
| 1336 Info readers. Next, try to add lots of cross-referencing and logical | |
| 1337 markup, and then node structure. | |
| 1338 | |
| 1339 Address both end users and developer issues. You may not be the | |
| 1340 maintainer forever. | |
| 1341 | |
| 1342 If you are maintaining a package that is part of the GNU Emacs | |
| 1343 distribution, you'll likely find that you occasionally synchronize your | |
| 1344 package with the GNU Emacs sources. When you synch a file, | |
| 1345 conventionally you should place a comment just above the standard | |
| 1346 @code{;;; Code} comment that looks like this: | |
| 1347 | |
| 1348 @example | |
| 1349 ;; Synched with: | |
| 1350 ;; GNU Emacs 21.1, 2002-02-08, Stephen Turnbull <stephen@@xemacs.org> | |
| 1351 @end example | |
| 1352 | |
| 1353 This comment is a status flag; the ChangeLog doesn't really give the | |
| 1354 same information. | |
| 1355 | |
| 1356 Do maintain a detailed ChangeLog. | |
| 1357 | |
| 1358 @node Issues, , Documenting Packages, Packaging | |
| 693 | 1359 @section Issues |
| 1360 | |
| 694 | 1361 To be completed. |
| 693 | 1362 |