-This only needs to be done once, when the package is first added to the
-@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.
-
-This is unfortunate; it works pretty well once set up, but can cause
-confusion when first building a package in the @xpms{} context. In
-particular, if the @code{package-directory-map} entry for a required
-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
-a Lisp script, have values substituted for variables, and then written
-out (appropriately quoted) into a loadable Lisp file, to be consed into
-the @file{package-index.el} list at the FTP archives. That list is
-structured as an alist with package names as keys. The package data is
-a plist. Do not rely on this, as it may change. If you have a good
-reason for relying on it, let the maintainers know and we may
-incorporate it in a future revision of the @xpms{} standard.
-
-There are several kinds of fields, distinguished by how they get their
-values. There are literals written into @file{package-info.in} by the
-package maintainer. There are variables substituted in by the build
-process, some computed, and others written as values of @file{make}
-variables in the @file{Makefile} by the package maintainer. There are a
-few implementation constants, some of which are simply the default value
-for obsolete fields.
-
-The @file{package-info.in} literals provided by the maintainer generally
-should not change over the life of the package. (The exception is the
-@samp{provides} field, which should be generated, but isn't yet.)
-Values described as ``literal'' below are unquoted literal test. These
-are normally interpreted as symbols by the package build process. The
-maintainer literals are
-
-@table @asis
-@item @var{package_name}
-A literal. The only unnamed ``field,'' the name of the package.
-
-@item distribution
-A literal, either @samp{xemacs} (for generic packages) or @samp{mule}
-(for packages requiring Mule). @xref{Package Terminology}.