From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie_JWA Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: Compilation order. Help with makefiles, please! Date: Wed, 29 Aug 2007 11:57:14 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1521211507==" X-Trace: sea.gmane.org 1188381420 15026 80.91.229.12 (29 Aug 2007 09:57:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2007 09:57:00 +0000 (UTC) Cc: bug-cc-mode@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Richard Stallman Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Wed Aug 29 11:56:57 2007 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by lo.gmane.org with esmtp (Exim 4.50) id 1IQKI7-0000iJ-4p for sf-cc-mode-help@m.gmane.org; Wed, 29 Aug 2007 11:56:51 +0200 Original-Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id A690D124E2; Wed, 29 Aug 2007 02:56:50 -0700 (PDT) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IQKI1-0002D8-WD for cc-mode-help@lists.sourceforge.net; Wed, 29 Aug 2007 02:56:46 -0700 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1IQKI1-0004Ep-4Z for cc-mode-help@lists.sourceforge.net; Wed, 29 Aug 2007 02:56:46 -0700 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IQKHf-0003mf-9H for bug-cc-mode@gnu.org; Wed, 29 Aug 2007 05:56:23 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1IQKHh-0008UA-Ir for bug-cc-mode@gnu.org; Wed, 29 Aug 2007 05:56:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on monty-python X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=HTML_FONT_BIG,HTML_MESSAGE autolearn=no version=3.1.0 Original-Received: from gw-eur4.philips.com ([161.85.125.10]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1IQKHg-0008Q3-7t; Wed, 29 Aug 2007 05:56:24 -0400 Original-Received: from smtpscan-eur6.philips.com (smtpscan-eur6.mail.philips.com [130.144.57.169]) by gw-eur4.philips.com (Postfix) with ESMTP id D217949732; Wed, 29 Aug 2007 09:56:08 +0000 (UTC) Original-Received: from smtpscan-eur6.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 89245D1F; Wed, 29 Aug 2007 09:56:08 +0000 (GMT) Original-Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur6.philips.com (Postfix) with ESMTP id 5CAC7C3B; Wed, 29 Aug 2007 09:56:08 +0000 (GMT) Original-Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id C1A09AA; Wed, 29 Aug 2007 09:56:07 +0000 (GMT) Sensitivity: X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.5FP2HF329 | April 6, 2007) at 29/08/2007 11:59:21 X-Detected-Kernel: Solaris 8 (2) X-Spam-Score: 0.3 (/) 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 0.1 HTML_40_50 BODY: Message is 40% to 50% HTML 0.0 HTML_MESSAGE BODY: HTML included in message 0.2 HTML_FONT_BIG BODY: HTML tag for a big font size X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: cc-mode-help-bounces@lists.sourceforge.net Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:4709 gmane.emacs.devel:77322 Archived-At: --===============1521211507== Content-type: multipart/alternative; Boundary="0__=4EBBF9D5DFBB28F58f9e8a93df938690918c4EBBF9D5DFBB28F5" Content-Disposition: inline --0__=4EBBF9D5DFBB28F58f9e8a93df938690918c4EBBF9D5DFBB28F5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi, Richard! On Sunday 26th August 2007 you wrote: > > For instance, if you put the macros etc. into one file whose nam= e > > comes alphabetically before the rest, maybe everything will work= > > reliably. > Surely the right tool for this job is the (or a?) makefile? If we= 're > going to fix the problem, we might as well fix it properly. >A fix in the makefile is better than no fix, but it is troublesome >because it would require major changes in something which is now very >simple. Is "major" not an exaggeration? The sort of change I suggested (record= ing the precise dependencies between the cc-*.elc files) would be fairly localised in effect. It could set a precedent for further changes, though. I think the makefile is simple because it doesn't reflect the inherent complexity of Emacs (or, at least, of CC Mode), and this is why compili= ng CC Mode is troublesome. >Practically speaking, we would be much better off if you could >solve this by changes in the cc-mode files themselves. I can't see how this can be done. The case I am thinking about is when= a change happens in cc-langs.el, say the introduction of a new language variable c-foo - this is what I changed in a bug fix last week. The sequence of compilations now needed is this: (i) Compile cc-langs.el; this puts the details of c-foo into a macro in= cc-langs.elc. (ii) Compile cc-engine.el and cc-mode.el; from the cc-langs macro, the first generates (defvar c-foo "Doc string.") in cc-engine.elc. The second generates (in effect), the following in= CC Mode's initialisation in cc-mode.elc: (setq cc-foo (cond ((eq major mode 'c-mode) "c-foo") ((eq major mode 'c++-mode) "c++-foo") .....)) 0 1 2 3 4 5 6 7= 3 Thus changing cc-langs.el makes a recompiliation of cc-{mode,engine}.el= necessary. I can't see how this can be done sensibly within the CC Mod= e files. Possibly, cc-{mode,engine}.el could, at compilation time, get t= he timestamps for cc-langs.el{,c}, compare them, and recursively compile cc-langs.el if necessary. But this is a horrible idea. Or were you thinking of a different troublesome case? -- Alan Mackenzie (Nuremberg, Germany).= --0__=4EBBF9D5DFBB28F58f9e8a93df938690918c4EBBF9D5DFBB28F5 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi, Richard!

On Sunday 26th August 2007 you wrote:<= br>
>    > For instance, if you put th= e macros etc. into one file whose name
>    > comes alphabetically before the rest, maybe ever= ything will work
>    > reliably.

>    Surely the right tool for this job is the (or a?) mak= efile?  If we're
>    going to fix the problem, we might as well fix it pro= perly.

>A fix in the makefile is better than no fix, but it is troublesome<= br> >because it would require major changes in something which is now ve= ry
>simple.

Is "major" not an exaggeration?  Th= e sort of change I suggested (recording
the precise dependencies between the cc-*.elc file= s) would be fairly
localised in effect.  It could set a preceden= t for further changes,
though.

I think the makefile is simple because it doesn't = reflect the inherent
complexity of Emacs (or, at least, of CC Mode), an= d this is why compiling
CC Mode is troublesome.

>Practically speaking, we would be much better = off if you could
>solve this by changes in the cc-mode files themselves.

I can't see how this can be done.  The case I am thinking about is= when a
change happens in cc-langs.el, say the introductio= n of a new language
variable c-foo - this is what I changed in a bug f= ix last week.  The
sequence of compilations now needed is this:
(i) Compile cc-langs.el; this puts the details of = c-foo into a macro in
  cc-langs.elc.
(ii) Compile cc-engine.el and cc-mode.el; from the= cc-langs macro, the
  first generates
    (defvar c-foo "Doc string."= ;)
  in cc-engine.elc.  The second generate= s (in effect), the following in
  CC Mode's initialisation in cc-mode.elc:

    (setq cc-foo
     (cond
      ((eq major mode 'c-mode) &quo= t;c-foo")
      ((eq major mode 'c++-mode) &q= uot;c++-foo")
      .....))
     
0         1     &nbs= p;   2         3         4=         5         6   &nb= sp;     7  3
Thus changing cc-langs.el makes a recompiliation o= f cc-{mode,engine}.el
necessary.  I can't see how this can be done = sensibly within the CC Mode
files.  Possibly, cc-{mode,engine}.el could, = at compilation time, get the
timestamps for cc-langs.el{,c}, compare them, and recursively compile
cc-langs.el if necessary.  But this is a horr= ible idea.

Or were you thinking of a different troublesome ca= se?

--
Alan Mackenzie (Nuremberg, Germany). = --0__=4EBBF9D5DFBB28F58f9e8a93df938690918c4EBBF9D5DFBB28F5-- --===============1521211507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============1521211507==--