[This report is not related to XEmacs directly but to a lot of other
 packages containing elisp-modules]


Let me begin with the problem:

- There are existing two different flavors of the Emacs editor which
  can run the same modules. Nevertheless the produced byte-code is not
  compatible so it can not be shared between them.

- Currently (x)emacs is supported by RH only sparely; a lot of packages
  are providing emacs modules in their source tar-balls, but they are
  not available in the binaries -- especially not for XEmacs (which
  rulez ;) ).


In the following considerations it is to differ between:
1. byte-code (*.elc)
2. source-code (*.el)
3. data
4. system-depending executables
5. code being executed at system^WEmacs start (currently located in
   sitestart.d directories)


I am assuming that:

- modules shall be available for both XEmacs and GNU Emacs; especially
  for XEmacs because it rulez
- byte-code(1) can not be shared
- source-code(2), data(3) + executables(4) can be shared
- there should be shared as much as possible
- site-start-files(5) should not be compiled but marked as %config-files
- it is not a solution to put modules into the emacs and xemacs RPMS. There
  are too much modules to catch them all, the (x)emacs packages will be
  difficulty to maintain and because the shipped (x)emacs-packages are very
  conservative, people like I who are using gamma versions will missing
  all these modules.


My experiences have shown that the init-stuff(5) can be shared also; but
because XEmacs is more powerful in handling `autoload' functions (you
know: XEmacs rulez) there must be taken special care. I will explain it
below...



My suggestion for the future Red Hat (X)Emacs package strategy is:

- binaries(1) are installed under
  * /usr/lib/xemacs/xemacs-packages/lisp/<packagename> for XEmacs. I don't
    know if .../xemacs-packages/... is the best choice. XEmacs knows a
    `site-packages' directory which seems to be more applicably. To keep
    backward compatibility `xemacs-packages' was chosen.
  * /usr/share/emacs/site-lisp/<packagename> for GNU Emacs; if there
    are only one or two files they can be installed directly in the
    site-lisp directory. Because of the autoload-mechanism of XEmacs
    that is not applicably there.

- a new directory `/usr/share/emacs-common' must be added where
  * sources(2) get installed in `lisp/<packagename>'; there will be
    added symlinks to them in the binary-directories mentioned above
  * data(3) get installed in etc/ or somewhere else;
    `/usr/lib/xemacs/xemacs-packages/etc' and `/usr/share/emacs/etc'
    will be symlinks to this etc/ directory
  * a directory `sitestart.d' exists and contains site-start files(5)

- executables(4) get installed somewhere else

- `/usr/lib/xemacs/xemacs-packages/lisp/sitestart.d' and
  `/usr/share/emacs/lisp/sitestart.d' will be symlinks to
  `/usr/share/emacs-common/sitestart.d'. There the init-files(5) will be
  installed



The realization in .spec-files:

  I have submitted some RPMS containing elisp-modules to rhcontrib.bero.org
  (most recent one is MagicPoint-el following the most of my suggestions).

  The .spec files are ugly -- especially because of the 50 lines of macros
  at the beginning. But these macros (paths, compilation commands) can be
  shared between all packages providing elisp-modules. Therefore there
  should be added some support to RPM...

  The real building and installation happens twice -- for each emacs one
  time. The installation is nearly the same for both; perhaps there
  exists some RPM-magic which allows it to embed it into a single macro.

  To allow building of the RPM if one of Emacs or XEmacs is not installed
  I test for their existence and build only possible subpackages. In
  official RH packages this part can be omitted probably...

  Altogether it should be possible to keep the spec-files clean and
  simple.



Difficulties:

  The XEmacs autoload mechanism:
    XEmacs has an own packaging-concept allowing the automatic
    generation of

|               (autoload 'feature "place" "doc" ...)

    statements being executed at system-start. To enable it there must
    be added only a ";;;###autoload" comment before the <feature> and
    XEmacs be called with

|     xemacs -vanilla -batch -l autoload -f batch-update-directory .

    A similar mechanism is existing for customizations. For details see
    etc/BETA -> "Manual procedures for package management"

    Finally there are two new files generated: `auto-autoloads.el' and
    `custom-load.el'. To avoid conflicts with other packages, each
    package must have its own directory.

    An advantage of this mechanism is that auto-load stuff of <feature>
    (documentation, interactive-flag) is kept in sync with the code. The
    old method can lead to dangling or incorrect autoloads.

    To prevent the interfering of manual and automatic autoloading in
    the init-files I suggest something like:

|         (unless (featurep 'MagicPoint-autoloads)
|            (autoload 'mgp-mode "mgp-mode" "Major..." t nil))
                                    
    The `MagicPoint-autoloads' feature will be defined by the XEmacs
    autoload mechanism.

  RPM does not support emacs-macros currently:
    Either they will be added explicitly by the rpm-maintainer or
    an autoload-mechanism will be added to RPM. Latter means that
    packages can place files under /etc/rpm which will be loaded by
    rpm automatically. Currently they must be entered into the
    `macrofiles' variable manually.