From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: byte compiler warnings when bootstrapping Date: Sun, 21 Oct 2007 15:38:06 -0400 Message-ID: References: <200710210738.l9L7cIGs012673@oogie-boogie.ics.uci.edu> <200710211558.l9LFwIBv003882@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1192995505 10566 80.91.229.12 (21 Oct 2007 19:38:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Oct 2007 19:38:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 21 21:38:25 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ijgcw-00074c-6Y for ged-emacs-devel@m.gmane.org; Sun, 21 Oct 2007 21:38:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ijgco-0001SM-2D for ged-emacs-devel@m.gmane.org; Sun, 21 Oct 2007 15:38:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ijgcj-0001QT-U1 for emacs-devel@gnu.org; Sun, 21 Oct 2007 15:38:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ijgci-0001P1-GW for emacs-devel@gnu.org; Sun, 21 Oct 2007 15:38:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ijgci-0001Ou-9R for emacs-devel@gnu.org; Sun, 21 Oct 2007 15:38:08 -0400 Original-Received: from bc.sympatico.ca ([209.226.175.184] helo=tomts22-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ijgch-000463-Qb for emacs-devel@gnu.org; Sun, 21 Oct 2007 15:38:08 -0400 Original-Received: from ceviche.home ([74.12.205.156]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20071021193806.JBPW18413.tomts22-srv.bellnexxia.net@ceviche.home> for ; Sun, 21 Oct 2007 15:38:06 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 5DC85B41C1; Sun, 21 Oct 2007 15:38:06 -0400 (EDT) In-Reply-To: <200710211558.l9LFwIBv003882@oogie-boogie.ics.uci.edu> (Dan Nicolaescu's message of "Sun\, 21 Oct 2007 08\:58\:18 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:81396 Archived-At: >> > 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 ) following the same idea as (defvar ). 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 ) would work better. Along similar lines I'd like to add a (require-lazily ) 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