Re: byte compiler warnings when bootstrapping

[Bob Rogers <rogers-emacs@rgrjr.dyndns.org>]

   From: Stefan Monnier <monnier@iro.umontreal.ca>
   Date: Sun, 21 Oct 2007 15:38:06 -0400

   . . .

   Along similar lines I'd like to add a

     (require-lazily <feature>)

   which would behave similarly to `require' except that the byte-compiler
   would replace it with a bunch of autoloads.  so the package would only be
   "required" when one of its functions was used.

   In any case, for the issue of "dependencies" (e.g. calling
   `Info-read-node-name' after `info', or calling `help-buffer' after
   `help-setup-xref') I'm not sure what we should ideally do, but the
   require-lazily seems like an acceptable solution.

	   Stefan

Since (IIUC) these are "internal" functions in one package that are
called from another, it seems better to mark them as such at the point
of definition, rather than in some random place in the files that call
them.

   For example, suppose we defined a ";;;API" tag line (or preferably
something less cryptic) to put before the definitions of functions that
are called elsewhere, by analogy with ";;;AUTOLOAD".  Then, a function
like batch-update-autoloads could be written that extracted these tagged
definitions into "declare-function" forms, building an "api-defs.el"
file that would be loaded into batch-byte-compile jobs in order to
suppress the "undefined function" warnings without requiring them to be
loaded.  This also has the benefit of explicitly identifying function
definitions that are used elsewhere within Emacs, despite seeming to be
internal, as a warning to people who might otherwise carelessly change
their interface.

   Given that much, it then ought to be trivial for the byte compiler to
insert

	(or (fbound 'foo-api-function)
	    (require 'foo))

(or something similar to what autoloading does) before the point of call
for each such function, giving the same effect as "require-lazily".

   Note that "api-defs.el" would not be loaded into emacs except when
compiling, nor would it ever be installed.  That way, these "internal
API" functions would remain internal as far as non-Emacs packages are
concerned.

   Thoughts?

					-- Bob Rogers
					   http://rgrjr.dyndns.org/