I'm trying to write an RPM script that will let me have multiple
coexisting builds of XEmacs (e.g., xemacs, xemacs-mule, and xemacs-gtk).
I've hit a few ... um ... features that make that hard. The major one
is the DOC file. I can put each DOC file in a separate directory, but
I'd rather have them in the usual place, but called, e.g., DOC,
DOC.mule, and DOC.gtk.
I can change the name of DOC before installation ... except that the
install-arch-dep rule in Makefile.in.in has the name DOC hardcoded in.
Okay, so I can install and then change the name. The hassle there is
that DOC is installed into .../lib/${instvardir}/${configuration}, and
the value of ${configuration} is nontrivial to determine from an RPM
script (not impossible, just a bit messy).
A glimmer of hope is available from src/doc.c, where the
Snarf-documentation function lives. It takes the name of the DOC file
as a parameter! But Snarf-documentation is called from loadup.el, where
it passes the constant string "DOC".
So what are the chances of a patch being accepted that does the
following?
1) Add an option to configure for specifying the DOC file name.
2) Do a replacement on Makefile.in.in for that name.
3) Put an entry into config.h specifying the name of the DOC file.
4) Remove the parameter from Snarf-documentation; loadup.el now just
calls "(Snarf-documentation)".
5) Have doc.c use the config.h entry to specify the file name, instead
of the current parameter.
It might be desirable to do something similar for the name of the
binary, although I note this snippet in loadup.el:
;; #### BILL!!!
;; If we want to dump under a name other than `xemacs', do that here!
;; ((featurep 'gtk) "xemacs-gtk")
--
Jerry James