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: Recursive compilation? Date: Tue, 31 May 2011 18:52:17 -0300 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306878789 25349 80.91.229.12 (31 May 2011 21:53:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 31 May 2011 21:53:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 31 23:53:05 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QRWs2-0006bu-07 for ged-emacs-devel@m.gmane.org; Tue, 31 May 2011 23:53:02 +0200 Original-Received: from localhost ([::1]:42221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRWs0-0007ef-Ts for ged-emacs-devel@m.gmane.org; Tue, 31 May 2011 17:53:00 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRWrg-0007e8-4Q for emacs-devel@gnu.org; Tue, 31 May 2011 17:52:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRWre-0004QY-H5 for emacs-devel@gnu.org; Tue, 31 May 2011 17:52:40 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:38175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRWre-0004QU-7L for emacs-devel@gnu.org; Tue, 31 May 2011 17:52:38 -0400 Original-Received: from [190.3.23.250] (port=52708 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QRWrd-0001Sa-PN; Tue, 31 May 2011 17:52:38 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 04DA5660DD; Tue, 31 May 2011 18:52:18 -0300 (ART) In-Reply-To: (Lars Magne Ingebrigtsen's message of "Tue, 31 May 2011 22:44:09 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:140002 Archived-At: > The obvious "gotcha" here is that one probably shouldn't try to > (recursively) byte-compile files in directories that we don't have write > access to. So if somebody has set their load-path to my directory, and > I have an old .elc file there, then this function shouldn't try to > compile that file, too. Right, cyclic require loops can definitely happen in such cases. But they're easy to break. > The other caveat is that Makefiles typically first mark all files that > are to be compiled, and then compile them. This would then possibly > lead to some files being compiled twice. However, that could be worked > around by `byte-compile-file-recursively' not compiling a file that it's > been asked to compile if the .elc file is newer than the .el file. It's also a problem with parallel make. > I have a feeling that this won't be very difficult to implement, but it > needs meddling with the C layer, since `require' is a C function. But I > think it would make compiling Emacs after a "bzr update" a lot less > likely to break. Another approach is to build a set of makefile dependencies from the `require' calls. I did that at some point in the past. It wasn't too hard to do. But there are also the cases of preloaded files, as well as autoloaded macros/functions. I'm personally using a different hack which doesn't solve all those problems either but is simple and doesn't suffer from as many problems in my experience: prefer loading the .el file if it's more recent. Stefan