From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: Release of CC Mode 5.31 Date: Wed, 7 Dec 2005 18:14:18 +0000 (GMT) Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1133979668 19228 80.91.229.2 (7 Dec 2005 18:21:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 7 Dec 2005 18:21:08 +0000 (UTC) Cc: Eli Zaretskii , bug-cc-mode@gnu.org, mast@lysator.liu.se, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Wed Dec 07 19:20:59 2005 Return-path: Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ek3oq-0004KM-Hm for sf-cc-mode-help@m.gmane.org; Wed, 07 Dec 2005 19:15:08 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id C28AC88AFE; Wed, 7 Dec 2005 10:15:06 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1Ek3oF-0000fB-Vu for cc-mode-help@lists.sourceforge.net; Wed, 07 Dec 2005 10:14:31 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44) id 1Ek3oE-0003SC-Ah for cc-mode-help@lists.sourceforge.net; Wed, 07 Dec 2005 10:14:31 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Ek3na-0006ia-0z for bug-cc-mode@gnu.org; Wed, 07 Dec 2005 13:13:50 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1Ek3pF-0001YL-NJ for bug-cc-mode@gnu.org; Wed, 07 Dec 2005 13:15:34 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ek3pE-0001X3-8H; Wed, 07 Dec 2005 13:15:33 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id SAA00927; Wed, 7 Dec 2005 18:14:19 GMT X-Sender: root@acm.acm Original-To: "Richard M. Stallman" In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 1.0 FORGED_RCVD_HELO Received: contains a forged HELO Original-Sender: cc-mode-help-admin@lists.sourceforge.net Errors-To: cc-mode-help-admin@lists.sourceforge.net X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Bug reports, feature requests, and general talk about CC Mode. List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 7 Dec 2005 18:14:18 +0000 (GMT) Xref: news.gmane.org gmane.emacs.cc-mode.general:2765 gmane.emacs.devel:47124 Archived-At: On Wed, 7 Dec 2005, Richard M. Stallman wrote: > After I saw the problem, but before I reported it, I recompiled all > the cc-*.el files, by "make recompile". Perhaps that command does not > compile the files in the order you mention. It would be nice if it > did that automatically. >There is no Emacs feature to control order of compilation, >so there would be no easy way to make that automatic. >However, I wonder about this: > > After downloading the new cc-langs.el, you need to byte-compile first > > cc-langs.el (which builds the macro c-init-language-vars), then > > cc-mode.el (which expands this macro (in the defun > > c-init-language-vars-for)). >Why is it crucial to compile cc-langs.el before compiling cc-mode.el? To be honest, I'm not sure any more whether this is accurate. cc-mode uses a macro (c-init-language-vars) in cc-langs which generates a massive setq form for all the language dependant variables. This macro is expanded 7 times, once for each constituent language. So, if cc-mode picks up an (old) cc-langs.elc in preference to a (newer) cc-langs.el, things will fail. >Once you have deleted cc-langs.elc, compilation of cc-mode.el will use >the source file, cc-langs.el. Does compilation of cc-mode.el fail to >work properly with the interpreted cc-langs.el? It should work fine with the interpreted cc-langs.el, as long as it doesn't load the (older) cc-langs.elc instead. Deleting an outdated cc-langs.elc should definitely make it work. -- Alan. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click