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: lisp/emacs-lisp/cl-loaddefs.el in git archive Date: Sat, 1 Aug 2009 18:08:39 -0400 Message-ID: References: <8663d748xf.fsf@blue.stonehenge.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1249164556 31054 80.91.229.12 (1 Aug 2009 22:09:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Aug 2009 22:09:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: merlyn@stonehenge.com (Randal L. Schwartz) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 02 00:09:10 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 1MXMlK-0004g0-3x for ged-emacs-devel@m.gmane.org; Sun, 02 Aug 2009 00:09:10 +0200 Original-Received: from localhost ([127.0.0.1]:58348 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXMlJ-0006b2-EU for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2009 18:09:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MXMlD-0006Zl-Ec for emacs-devel@gnu.org; Sat, 01 Aug 2009 18:09:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MXMl9-0006Z4-PF for emacs-devel@gnu.org; Sat, 01 Aug 2009 18:09:03 -0400 Original-Received: from [199.232.76.173] (port=59286 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXMl9-0006Z1-Ms for emacs-devel@gnu.org; Sat, 01 Aug 2009 18:08:59 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:35263 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 1MXMku-0006Ck-E9 for emacs-devel@gnu.org; Sat, 01 Aug 2009 18:08:59 -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 n71M8dCD008190; Sat, 1 Aug 2009 18:08:39 -0400 (EDT) In-Reply-To: <8663d748xf.fsf@blue.stonehenge.com> X-Mailer: Apple Mail (2.935.3) 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:113534 Archived-At: On Aug 1, 2009, at 15:43, Randal L. Schwartz wrote: > The file lisp/emacs-lisp/cl-loaddefs.el in the git archive is > problematic, > because a file cannot be both a tracked source and a build-output in > git. > Each build updates the file, thus dirtying the tree, requiring it to > be > checked in before a fetch or pull. It looks like it's storing md5 sums of the input files. Which means it'll be regenerated, but it's repeatable. Checking in the updated cl- loaddefs.el when one of the other files is changed (in this case apparently cl-macs.el) should keep things in sync. Depending on timestamps and makefile dependencies and such, it may still get rebuilt in the next build after an update, but the content will be unchanged. In fact it's probably more stable than lisp/loaddefs.el (which appears to use input file timestamps?) or configure (which is dependent on the version of autoconf installed). Rebuild those and you may well not get the content to match the repository, though functionally it'll probably be the same. I usually just throw away mine in favor of the one from the repository, unless I've actually made some changes. > Ahh, it appears that something is using it before it would have been > created > or updated. Kind of like "configure". > This would appear to be a build bug. Can someone who is more > familiar with this process help me understand why this is the way it > is, so I > can sort it out for the git archive? It's cached information from the various input elisp files, that doesn't change often, and takes a while to reconstruct. For distribution it should speed things up in end-user builds, vs processing all the elisp files for autoloads then. In the case of loaddefs.el, there's also a bootstrapping issue -- that's the file that tells Emacs where functions like update-directory-autoloads are to be found. I suspect it would be possible to make the files at build time, by explicitly indicating where to load the Lisp code necessary code for generating them, or using some non-Lisp mechanism for generating them. Or even scan all the files during loadup before dumping, but I think that would generate excessive garbage taking up space in the new image, and it'd mean rerunning the whole thing any time you make a change to one of the Emacs C source files and recompile. We have a few other generated files in the repository, like the configure script. It usually hasn't been a big problem, as long as the files get updated when necessary. Ken