Treatise on require

[Bill Wohler]

Is there a treatise on loading that shows best practices in the use of
require, autoload, defvar, eval-when-compile, eval-and-compile? I've
read the manual (repeatedly) and sort of understand each piece, but
don't have a good big picture.

Over time, nasty circular dependencies have reared their ugly head in
MH-E. For example, mh-e requires just about other file and just about
every other file requires mh-e. Just for fun there are mini-loops with
mh-customize and and mh-utils. This is currently handled by putting the
call to provides (in mh-e.el) before the various calls to require (whose
files require mh-e).

But it's very fragile.

I'm sort of thinking that it might be better to replace the require
calls with something like:

  (eval-when-compile
    (autoload 'foo "foo")
    (defvar foo))

This would placate the compiler without creating require loops.
Thoughts?

Also, has anyone written anything to build a call graph so that I might
be able to reorganize the files as another way to eliminate the loops.

Anyway, any feedback on this topic or pointers to existing discussions
would be extremely welcome. Thanks!

p.s. The elisp manual for eval-and-compile says this:

     If a macro has a helper function to build its result, and that
     macro is used both locally and outside the package, then
     `eval-and-compile' should be used to get the helper both when
     compiling and then later when running.

     If functions are defined programmatically (with `fset' say), then
     `eval-and-compile' can be used to have that done at compile-time
     as well as run-time, so calls to those functions are checked (and
     warnings about "not known to be defined" suppressed).

However, it doesn't say *how* eval-and-compile should be used. I have no
idea. Examples for both paragraphs would help.

-- 
Bill Wohler <address@hidden>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.