Re: Problems setting byte-compile-warnings to t

[Dan Nicolaescu <dann@ics.uci.edu>]

Glenn Morris <rgm@gnu.org> writes:

  > Richard Stallman wrote:
  > 
  > >     So the simplest fix would seem to adjust the buffer-local value in
  > >     inbuffer in the same way that byte-compile-close-variables does.
  > >
  > > I see a problem with that: such a change would persist after the end
  > > of the compilation.
  > 
  > Yes, but in an internal buffer used only by byte-compilation, so I
  > don't see the problem. Anyway...
  > 
  > > Here's another idea: add a function byte-compile-memq which always
  > > returns t if the second arg is t, and use that instead of memq to test
  > > membership in byte-compile-warnings.  That avoids the need to alter
  > > data provided by the user.
  > 
  > I installed a changes along these lines: byte-compile-warning-enabled-p.
  > 
  > I also took the opportunity to allow byte-compile-warnings to specify
  > a list of warnings to _disable_. Useful for compiling emacs-lisp/cl-*, IMO.

To take advantage of this new flags I added a new flag to
lisp/Makefile.in: BYTE_COMPILE_EXTRA_FLAGS
It is empty by default, and it is passed to the byte compiler.

It can be used like this:
make bootstrap BYTE_COMPILE_EXTRA_FLAGS="--eval '(setq byte-compile-warnings (quote (not unresolved)))'"
to not show the hundreds of undefined function warnings, this makes it
easier to look for other warnings until a solution is found for
undefined function warnings...