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