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: [Emacs-diffs] trunk r117152: Arrange to never byte-compile the generated -pkg.el file. Date: Mon, 26 May 2014 14:17:29 -0400 Message-ID: References: <87bnuldj9c.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1401128280 6156 80.91.229.3 (26 May 2014 18:18:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 May 2014 18:18:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 26 20:17:49 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WozT2-0005PL-QU for ged-emacs-devel@m.gmane.org; Mon, 26 May 2014 20:17:48 +0200 Original-Received: from localhost ([::1]:58027 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WozT2-0002uj-8Z for ged-emacs-devel@m.gmane.org; Mon, 26 May 2014 14:17:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WozSs-0002s6-4V for emacs-devel@gnu.org; Mon, 26 May 2014 14:17:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WozSk-0007Oe-Lf for emacs-devel@gnu.org; Mon, 26 May 2014 14:17:38 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WozSk-0007OZ-Hj for emacs-devel@gnu.org; Mon, 26 May 2014 14:17:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd/fU/2dsb2JhbABZgwaDSlK/a4EXF3SCJQEBAQECASMzKAsLGgIYDgICFBgNiCgIrxuifheBKY0eOhaCWYFJBJRilDeBaoFxgVsh X-IPAS-Result: ArYGAIDvNVNLd/fU/2dsb2JhbABZgwaDSlK/a4EXF3SCJQEBAQECASMzKAsLGgIYDgICFBgNiCgIrxuifheBKY0eOhaCWYFJBJRilDeBaoFxgVsh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="64245541" Original-Received: from 75-119-247-212.dsl.teksavvy.com (HELO pastel.home) ([75.119.247.212]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 26 May 2014 14:17:29 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 7B21C60203; Mon, 26 May 2014 14:17:29 -0400 (EDT) In-Reply-To: <87bnuldj9c.fsf@zigzag.favinet> (Thien-Thi Nguyen's message of "Mon, 26 May 2014 10:41:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172114 Archived-At: > affords us only =E2=80=98auto-save-file-name-p=E2=80=99 and =E2=80=98dir-= locals-file=E2=80=99 as > possible ways to exclude -pkg.el files, the latter probably a bit > easier since it's a variable, w/o modifying the filesystem. Indeed, the reason why *-pkg.el is currently recompiled is that the fix wasn't as simple as let-binding a variable telling byte-recompile-directory to ignore that file. This said, it should be fairly easy to add a variable (e.g. `byte-compile-ignored-files') for that purpose. > If modifying the filesystem is OK, Yuck! > All of these strike me as inelegant. Maybe now is good time to > address another issue of =E2=80=98byte-recompile-directory=E2=80=99, name= ly that > caller has no control over the order of the files processed. As > author of ELPA package =E2=80=98xpm=E2=80=99, i would like this control a= nd would > be willing to work a bit (i.e., manually specifying the desired > order) to get it. I imagine others might desire similarly. I think this is ill-advised. AFAIK the only kind of dependency that might deserve such a treatment is the one where foo.el is newer than foo.elc and where byte-compiling bar.el should not use the older foo.elc. But in the case of package.el there are no old elc files to avoid, so there's no need for dependencies. If you have another example where you think ordering of compilation matters, feel free to post it, so I can try to shoot it down ;-) Stefan