From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: compiler warnings Date: Sat, 29 Dec 2007 22:23:14 +0000 Message-ID: <20071229222314.GD10722@atlantic.linksys.moosehall> Reply-To: Adam Spiers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8k5N-0006am-4u for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 17:23:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8k5M-0006ZW-9W for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 17:23:16 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8k5M-0006ZR-6A for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 17:23:16 -0500 Received: from mail.beimborn.com ([70.84.38.100]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J8k5M-00019O-5D for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 17:23:16 -0500 Received: from mail.beimborn.com (localhost.localdomain [127.0.0.1]) by mail.beimborn.com (8.12.11.20060308/8.12.8) with ESMTP id lBTMNFEx016395 for ; Sat, 29 Dec 2007 16:23:15 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id lBTMNEHF016390 for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 22:23:14 GMT Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: org-mode mailing list Does anyone else get a lot of warnings during compile of org.el? In org-remember-insinuate: org.el:13175:9:Warning: assignment to free variable `remember-annotation-functions' org.el:13176:9:Warning: assignment to free variable `remember-handler-functions' In end of data: org.el:27707:1:Warning: the following functions might not be defined at runtime: gnus-summary-last-subject, rmail-show-message, calendar-forward-day, parse-time-string, calendar-goto-date, calendar-goto-today, calendar-iso-date-string, calendar-julian-date-string, calendar-astro-date-string, calendar-hebrew-date-string, calendar-islamic-date-string, calendar-french-date-string, calendar-bahai-date-string, calendar-mayan-date-string, calendar-coptic-date-string, calendar-ethiopic-date-string, calendar-persian-date-string, calendar-chinese-date-string org.el:27707:1:Warning: the following functions are not known to be defined: add-local-hook, table--at-cell-p, bbdb-record-name, bbdb-current-record, bbdb-record-getprop, vm-summarize, vm-follow-summary-cursor, vm-select-folder-buffer, vm-su-subject, vm-get-header-contents, vm-su-message-id, wl-summary-message-number, elmo-message-field, elmo-msgdb-overview-get-entity, wl-summary-buffer-msgdb, wl-summary-line-from, elmo-message-entity-field, wl-summary-line-subject, rmail-narrow-to-non-pruned-header, gnus-article-show-summary, dired-get-filename, bbdb-name, bbdb-company, bbdb, vm-isearch-update, vm-isearch-narrow, vm-beginning-of-message, elmo-folder-exists-p, wl-folder-get-elmo-folder, wl-summary-goto-folder-subr, wl-summary-jump-to-msg-by-message-id, wl-summary-redisplay, rmail-what-message, mh-index-previous-folder, mh-get-msg-num, mh-show-buffer-message-number, mh-display-msg, mh-header-display, mh-show-header-display, mh-get-header-field, mh-show, mh-show-show, mh-find-path, mh-visit-folder, mh-normalize-folder-name, mh-search-choose, mh-search, mh-show-msg, bibtex-generate-autokey, bibtex-beginning-of-entry, bibtex-parse-entry, bibtex-url, remember, remember-buffer-desc, add-to-diary-list, cdlatex-tab, org-export-latex-cleaned-string, speedbar-line-directory It seems pretty clear that these are all due to references on external packages which are not automatically loaded at start-up, and hence are (mostly?) harmless - but should we try to clear them up anyway? If so, what would the best way be? `autoload' or `eval-when-compile' are presumably better than just a bunch of stub defun and defvar statements, but maybe there's a better way?