custom-load.el and MH-E compatibility macros

[mike.kupfer at xemacs.org]

Another chapter in the continuing saga of producing an XEmacs package
with MH-E 8... :-)

When I try to build MH-E 8, I get a custom-load.el that looks like this:

    ;;; custom-load.el --- automatically extracted custom dependencies
    
    ;;; Code:
    
    (autoload 'custom-add-loads "cus-load")
    
    
    ;;; custom-load.el ends here

Notice the lack of calls to custom-add-loads.

I was able to generate a reasonable-looking custom-loads.el by visiting
<my_workspace>/xemacs-packages/mh-e and doing

    M-x Custom-make-dependencies RET lisp RET

from my currently running XEmacs process, which of course already has
MH-E loaded.  

Looking at the MH-E 8 source, I see that it doesn't invoke defcustom,
defface, or defgroup directly.  Instead, it defines deffoo-mh wrapper
macros and invokes *them*.

Custom-make-dependencies-1 looks for sexp's that start with "defcustom",
"defface", or "defgroup".  The regexp looks like it would find
invocations of defcustom-mh and friends (line numbers are for
lib/xemacs-21.4.19/lisp/cus-dep.el):

121		  (while (re-search-forward
122			  "^(defcustom\\|^(defface\\|^(defgroup"
123			  nil t)

But consider what it does when it has found a likely match:

124		    (beginning-of-line)
125		    (let ((expr (read (current-buffer))))
126		      ;; We need to ignore errors here, so that
127		      ;; defcustoms with :set don't bug out.  Of
128		      ;; course, their values will not be assigned in
129		      ;; case of errors, but their `custom-group'
130		      ;; properties will by that time be in place, and
131		      ;; that's all we care about.
132		      (ignore-errors
133			(eval expr))

We'll get the right results if defcustom-mh et al are already defined,
but nothing if they're not defined.

I'm not sure how to proceed.  

I'd rather not replace the deffoo-mh invocations with direct calls to
deffoo, since that approach seems unlikely to work for upstream.

I thought about moving the deffoo-mh definitions to their own file, and
modifying the build rules to load the macros before invoking
Custom-make-dependencies.  For example, if I define a new makefile macro
called CUSTOM_LOAD_PREMAKE, it could be null for most packages, but
something like "-l mh-macros" for MH-E.  Then the build rule for
custom-load.el could look like

$(AUTOLOAD_PATH)/custom-load.el: $(GENERATED_ELC_DEPENDENCIES)
	$(XEMACS_BATCH_CLEAN) $(LOAD_AUTOLOADS) -l cus-dep \
		$(CUSTOM_LOAD_PREMAKE) \
		-f Custom-make-dependencies $(AUTOLOAD_PATH)
	@touch $(AUTOLOAD_PATH)/custom-load.el
	@rm -f $(AUTOLOAD_PATH)/custom-load.el~

Comments?  Suggestions?

thanks,
mike