xemacs-beta: man/lispref/packaging.texi comparison

comparison man/lispref/packaging.texi @ 694:561ad704dc70

[xemacs-hg @ 2001-12-15 09:16:20 by stephent] hazmat recycling

author	stephent
date	Sat, 15 Dec 2001 09:16:21 +0000
parents	b05e2a249757
children	9cea8fcd2e61

comparison

equal deleted inserted replaced

-:b05e2a249757
+:561ad704dc70
 subdirectory is for use by the @xpms{} administration tools, and
 currently contains a @file{MANIFEST.@var{package-name}} file for each
 package to ensure that no cruft remains when a package is removed or
 updated.  The @file{lisp}, @file{etc}, and @file{lib-src} subdirectories
 are further subdivided, with a subdirectory for each package.  The
-@file{info} and @file{man} directories obey the respective documentation
+@file{info} directory obeys the usual conventions.
-systems' conventions.  @emph{I.e.}, the @file{info} directory is flat
+@emph{I.e.}, the @file{info} directory is flat
 with a(n) (optional) @file{dir} file and one (set of) info file(s) per
-package.  The @file{man} subdirectory is divided into sections.  As
+package.  The @file{man} subdirectory typically contains documentation
-mentioned, this structure is used for historical reasions, and it is
+sources, separated by package.  (It does not contain @file{man(1)}
-likely to change in the future.
+pages, as Emacs provides very few of them.)
 There are several standard package hierarchies, and administrators can
 configure others at build time, while users can configure others at run
 time.  The standard system hierarchies are all subdirectories of an
 @c #### This is possibly incorrect usage of "installation root."
 @samp{--package-path} option to @file{configure}, or at run-time by
 specifying the @code{EMACSPACKAGEPATH} environment variable.
 @xref{Packages,,,xemacs}.
 @c #### The following description is quite possibly inaccurate.
-@c Arrgh, Michael!
+@c Please, Michael, write some specs up!
 The default order of search is hierarchically determined.  First, the
 roots are ordered.  The @dfn{early} roots are the user-specific roots,
 typically @file{~/.xemacs}.  The @dfn{late} roots are the system roots,
 typically @file{/usr/local/lib/xemacs-21.4.6} and
 @file{/usr/local/lib/xemacs}, in that order.  All hierarchies for a
 @node The Package Release Engineer's View, , The Library Maintainer's View, Package Overview
 @subsection The Package Release Engineer's View
-Bu-wha-ha-ha-ha-ha!  If you aren't the package release engineer, you
+The XEmacs Package Release Engineer is responsible for keeping the
-@emph{don't want to know}.  If you @emph{are} the package release
+system coherent.  The changes to @file{packages/package-compile.el} and
-engineer, you have my condolences.  Rest (if you can get any rest)
+@file{packages/xemacs-packages/Makefile} required to make the package
-assured you are in my prayers.
+available to others, and for building SUMO tarballs, @emph{etc}, are
+done by the Package Release Engineer, not individual library
-To be completed.
+maintainers.
+The Package Release Engineer also maintains assorted infrastructure for
+actually making releases.  These are generally available for inspection
+in the @code{xemacs-builds} module in the CVS repository.
+@c #### To be completed.
 @c #### The following section is lifted verbatim from the XEmacs User's
 @c      Manual, file packages.texi.
 @node Package Terminology, Building Packages, Package Overview, Packaging
 requires any of your files, it must be explicitly added to the compile
 environment or loads/requires that search load-path will fail.  The
 changes that need to be made are
 @table @strong
-@item an entry in package-directory-map
+@item an entry in @code{package-directory-map}
 This tells the @xpms{} which distribution (currently
 @samp{xemacs-packages} or @samp{mule-packages}) your package is found
 in.  It then looks in the distribution subdirectory whose name is the
 same as the package's.
 @xpms{}.  (Well, when you randomly change the subdirectory layout, too.)
 Your changes to @file{package-compile.el} must be cleared and checked in
 by the XEmacs Package Release Engineer before your package will build
 correctly from a fresh checkout.
-Obviously all of this is really horrible, and would be totally
+This is unfortunate; it works pretty well once set up, but can cause
-inexcusable if I wasn't afraid the XEmacs Package Release Engineer would
+confusion when first building a package in the @xpms{} context.  In
-kill me if I complained loud enough for him to hear.  Maybe it will
+particular, if the @code{package-directory-map} entry for a required
-change some day....
+package
+@c #### including the package itself?
+is not found, the necessary requires will not be executed by
+@file{package-compile.el}.  If required functions are executed (under
+@code{eval-when-compile}), they won't be found and the compile will
+fail.  If required function is actually a macro, the byte compiler will
+not recognize that, compile a function call to the macro.  This will
+cause a run-time error because the byte-code interpreter does not know
+how to execute macros.  (Macros can always be expanded at compile-time,
+and this is more efficient.)
+If your package keeps some or all Lisp code somewhere other than the top
+directory, then an entry in @code{package-name-to-directory} is also
+necessary, or requires will fail, leading to the problems just described.
 @node package-info.in Fields, Makefile Variables, package-compile.el, Creating Packages
 The @file{package-info.in} structure is simply Lisp data, to be read by
 @node Issues, , Creating Packages, Packaging
 @section Issues
-``Issues''?  Mu-wha-ha-ha!  Ha-ha-ha!  Honeychile, they ain't nuthin'
+To be completed.
-@emph{but} ``issues'' at this point.  @xref{The Package Release
-Engineer's View}.

Mercurial > hg > xemacs-beta

comparison man/lispref/packaging.texi @ 694:561ad704dc70