Re: byte compiler warnings when bootstrapping

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

>> > With that and with adding a few more (eval-when-compile (require 'blah))
>> What is the use of (eval-when-compile (require 'blah)) in this context?
>> I expect it's the wrong solution.
> When the number of warnings for undefined functions is too high it
> might be better to just require the package that defines them.  But you
> might be right...

The bytecomp.el has code (which ssems not to work any more) that tries to
re-add the warnings in this case (turns the "unknown function" warnings you
get without the `require' into "not sure it'll be defined at runtime" with
the eval-when-compile require).

So it's not the right approach.  `eval-when-compile' should really be used
to require packages that provide a macro or something like that: something
you really need to properly compile the file.

I agree that we need something to turn off specific warnings.  Someone at
some point suggested (defun <foo>) following the same idea as (defvar <foo>).

I think it would be good.  Although I think I'd rather allow the
external-function-delcaration to give an arglist so that the bytecompiler
can check you passed the right number of arguments as well.  So maybe
something like

  (declare-function <foo> <fooarglist>)

would work better.

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