Re: MH-E 7.4.4 checked in

[Stefan <monnier@iro.umontreal.ca>]

> A new macro mh-require-cl was added.  As a result you need to remove the
> old .elc files before proper compilation of Emacs can happen.

Changing a macro's definition or worse changing a function into a macro
does require manual intervention (removal of some .elc files) but
adding a new macro should not require removing .elc files.

The reason why it turned out to be necessary in this case is because
mh-utils.el (where mh-require-cl is defined) and mh-customize.el require
each other.
This can be seen in the error messages posted by Eli:

     Checking d:/gnu/new/emacs/lisp/mh-e...
     Compiling d:/gnu/new/emacs/lisp/mh-e/mh-comp.el...
     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-e.el' newer than byte-compiled file
     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file
     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file

Notice how mh-utils.el appears twice: once first because it's required by
mh-e, and a second time because while loading mh-utils, it required
mh-custom which itself required mh-utils (which still hadn't been
provided).

I think this double-loading of mh-utils should be fixed.  A good way to do
that is to change mh-custom and mh-utils so they don't mutually require
each other.

By the way, the patch below is necessary if the double-loading of
mh-utils.el is fixed.


        Stefan


--- mh-utils.el	16 Jul 2004 10:18:02 -0400	1.6
+++ mh-utils.el	16 Jul 2004 11:13:12 -0400	
@@ -34,8 +34,9 @@
 ;;; Code:
 
 ;; Is this XEmacs-land? Located here since needed by mh-customize.el.
-(defvar mh-xemacs-flag (featurep 'xemacs)
-  "Non-nil means the current Emacs is XEmacs.")
+(eval-and-compile
+  (defvar mh-xemacs-flag (featurep 'xemacs)
+  "Non-nil means the current Emacs is XEmacs."))
 
 ;; The Emacs coding conventions require that the cl package not be required at
 ;; runtime. However, the cl package in versions of Emacs prior to 21.4 left cl