From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: build broken: no defun org-float-time. Who's guilty, and what does he propose? Date: Mon, 7 Sep 2009 19:39:32 -0400 Message-ID: <88A44246-FB18-46DB-B92D-00E1716F5F68@raeburn.org> References: <20090907092823.GA3210@muc.de> <83ws4a3b49.fsf@gnu.org> <0C7A6FC6-085D-4B7F-9DC0-FF0493876153@raeburn.org> <83tyze34fd.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1252366804 15759 80.91.229.12 (7 Sep 2009 23:40:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Sep 2009 23:40:04 +0000 (UTC) Cc: Emacs development discussions To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 08 01:39:57 2009 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 1MknoR-0001C0-6x for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2009 01:39:55 +0200 Original-Received: from localhost ([127.0.0.1]:48563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MknoQ-0007at-E7 for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2009 19:39:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MknoL-0007al-J3 for emacs-devel@gnu.org; Mon, 07 Sep 2009 19:39:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MknoH-0007Wa-3R for emacs-devel@gnu.org; Mon, 07 Sep 2009 19:39:49 -0400 Original-Received: from [199.232.76.173] (port=36429 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MknoG-0007WP-Pn for emacs-devel@gnu.org; Mon, 07 Sep 2009 19:39:44 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:57866 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mkno6-00077I-1w; Mon, 07 Sep 2009 19:39:42 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n87NdWPi018314; Mon, 7 Sep 2009 19:39:32 -0400 (EDT) In-Reply-To: <83tyze34fd.fsf@gnu.org> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:115103 Archived-At: On Sep 7, 2009, at 16:06, Eli Zaretskii wrote: > We have `features' and `load-history' to help us. Yes. > Files loaded by loadup.el are easily extracted by simple text > scanning, and the byte compiler itself indeed _is_ a prerequisite for > every other compilation. But if a minor comment change is made in the compiler source, must we recompile everything? We don't generally make .o files explicitly depend on the C compiler. Though, in the gcc project they probably do... so, yeah, maybe it's the way to go. > Btw, I don't understand what problem do you see with files preloaded > by loadup. They should simply be all prerequisites of temacs, and > that's it, right? Well, "emacs", not "temacs" which is just linked from the C code, but also I was assuming we wouldn't make the emacs binary an explicit dependency for the .elc files; otherwise, someone downloading and building a release will have to recompile all the elisp code even though the results will differ from everyone else's only in the first few comment lines. And I'm not sure if we want to list all those files as dependencies anyways. We might indeed want to recompile everything if subr.el changes, if we can't figure out what actually used stuff from that file. On the other hand, we probably don't want to recompile everything because lisp/language/georgian.el changed. (Conservatively speaking, I suppose we should, in case someone decided to redefine 'defcustom' there.) Actually, I think we want to rebuild if subr.elc changes, other than the comments indicating who compiled it and when, not just for all subr.el changes, and likewise for the compiler code.... Ken