From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie_JWA Newsgroups: gmane.emacs.devel Subject: Re: Compilation order. Help with makefiles, please! Date: Fri, 31 Aug 2007 10:57:38 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0764398442==" X-Trace: sea.gmane.org 1188550611 6545 80.91.229.12 (31 Aug 2007 08:56:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2007 08:56:51 +0000 (UTC) Cc: bug-cc-mode@gnu.org, acm@muc.de, alan.mackenzie_jwa@nxp.com, Stefan Monnier , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 31 10:56:48 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 1IR2Iw-0001f3-HV for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2007 10:56:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IR2Iw-0005hs-3C for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2007 04:56:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IR2Is-0005hn-35 for emacs-devel@gnu.org; Fri, 31 Aug 2007 04:56:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IR2Iq-0005hY-0B for emacs-devel@gnu.org; Fri, 31 Aug 2007 04:56:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IR2Ip-0005hV-P7 for emacs-devel@gnu.org; Fri, 31 Aug 2007 04:56:31 -0400 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 1IR2Im-0006oZ-Tv; Fri, 31 Aug 2007 04:56:29 -0400 Original-Received: from smtpscan-eur7.philips.com (smtpscan-eur7.mail.philips.com [130.144.57.172]) by gw-eur4.philips.com (Postfix) with ESMTP id 2456749724; Fri, 31 Aug 2007 08:56:00 +0000 (UTC) Original-Received: from localhost (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with SMTP id 5F19818BF; Fri, 31 Aug 2007 08:55:41 +0000 (GMT) Original-Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur7.philips.com (Postfix) with ESMTP id 8FBD6128E; Fri, 31 Aug 2007 08:54:26 +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 9754698; Fri, 31 Aug 2007 08:54:26 +0000 (GMT) In-Reply-To: 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 31/08/2007 10:57:41 X-Detected-Kernel: Solaris 8 (2) 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:77476 Archived-At: --===============0764398442== Content-type: multipart/alternative; Boundary="0__=4EBBF9DBDFA39A028f9e8a93df938690918c4EBBF9DBDFA39A02" Content-Disposition: inline --0__=4EBBF9DBDFA39A028f9e8a93df938690918c4EBBF9DBDFA39A02 Content-type: text/plain; charset=US-ASCII Hi, Richard and Stefan, Richard Stallman wrote on 2007-08-31 09:34:55: > An "easy" solution is to prefer reading the newer .el files rather > than the older .elc when `requiring' a file during > byte-compilation. Stefan, the essential issue here is to ensure that cc-{mode,engine}.el actually get recompiled after a change in cc-langs.el. This needs stuff in the makefile. > To solve this problem, it would have to load the newer .el file > even if the feature is already provided. There is stuff like this in cc-bytecomp.el - cc-require, cc-provide, and so on. I've a feeling that cc-require might load the .el file rather than the .elc, but I'm not sure at the moment. Byte compiling cc-langs.el is a good idea anyway, to check for errors in cc-langs. > That is quite different from `require', and I don't think we should > change `require' to do that. But we could add it as a separate new > feature, perhaps called `compilation-require'. > What do you think about that? cc-bytecomp implements this sort of thing. Possibly its functionality could be absorbed into Emacs 23. -- Alan Mackenzie (Nuremberg, Germany). --0__=4EBBF9DBDFA39A028f9e8a93df938690918c4EBBF9DBDFA39A02 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi, Richard and Stefan,

Richard Stallman <rms@gnu.org> wrote on 2007-08-31 09:34:55:

>     An "easy" solution is to prefer reading the newer .el files rather
>     than the older .elc when `requiring' a file during
>     byte-compilation.

Stefan, the essential issue here is to ensure that cc-{mode,engine}.el
actually get recompiled after a change in cc-langs.el.  This needs stuff
in the makefile.
 
>     To solve this problem, it would have to load the newer .el file
>     even if the feature is already provided.

There is stuff like this in cc-bytecomp.el - cc-require, cc-provide, and
so on.  I've a feeling that cc-require might load the .el file rather
than the .elc, but I'm not sure at the moment.  Byte compiling
cc-langs.el is a good idea anyway, to check for errors in cc-langs.

> That is quite different from `require', and I don't think we should
> change `require' to do that.  But we could add it as a separate new
> feature, perhaps called `compilation-require'.

> What do you think about that?

cc-bytecomp implements this sort of thing.  Possibly its functionality
could be absorbed into Emacs 23.

--
Alan Mackenzie (Nuremberg, Germany).
--0__=4EBBF9DBDFA39A028f9e8a93df938690918c4EBBF9DBDFA39A02-- --===============0764398442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============0764398442==--