From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Current CVS doesn't bootstrap Date: Sun, 7 Nov 2004 15:09:44 -0600 (CST) Message-ID: <200411072109.iA7L9iR02078@raven.dms.auburn.edu> References: <01c4c3f3$Blat.v2.2.2$7e8aa060@zahav.net.il> <01c4c41c$Blat.v2.2.2$0fa338a0@zahav.net.il> <200411062248.iA6MmEm29919@raven.dms.auburn.edu> <01c4c487$Blat.v2.2.2$d4c31400@zahav.net.il> <200411071743.iA7Hhfi01732@raven.dms.auburn.edu> <200411071933.iA7JXul02016@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1099861845 16644 80.91.229.6 (7 Nov 2004 21:10:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 7 Nov 2004 21:10:45 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 07 22:10:37 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CQuJ3-0008Hy-00 for ; Sun, 07 Nov 2004 22:10:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQuRM-00017N-Lu for ged-emacs-devel@m.gmane.org; Sun, 07 Nov 2004 16:19:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CQuRF-000175-I3 for emacs-devel@gnu.org; Sun, 07 Nov 2004 16:19:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CQuRF-00016t-5o for emacs-devel@gnu.org; Sun, 07 Nov 2004 16:19:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQuRF-00016q-29 for emacs-devel@gnu.org; Sun, 07 Nov 2004 16:19:05 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CQuIp-00040B-EO for emacs-devel@gnu.org; Sun, 07 Nov 2004 16:10:23 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id iA7LAFFu018276; Sun, 7 Nov 2004 15:10:15 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id iA7L9iR02078; Sun, 7 Nov 2004 15:09:44 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: piet@cs.uu.nl In-reply-to: (message from Piet van Oostrum on Sun, 07 Nov 2004 21:37:50 +0100) 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: main.gmane.org gmane.emacs.devel:29534 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29534 Piet van Oostrum wrote: An alternative would be to remove only those .elc files that are older than their corresponding .el files. That, or Andreas' suggestion, could actually be an improvement for the proposed `make bootstrap-build', assuming our (apparent) consensus from a previous thread got implemented. But I believe that two problems would remain. It would seem that some changes in byte-compilation may require recompiling everything. I believe nothing can be done about that. Before I started systematically using `make maintainer-clean', I encountered several problems where the .elc file was wrong even though _newer_ than the .el file. For instance, `C-x v u' in VC produces such situations. I guess this problem could be avoided by manually removing the .elc file each time after you do `C-x v u' or otherwise cause this type of situation. But this assume that most users are aware of this danger. It also is easy to forget, even if you know. If you run Emacs from the place you built it, then you might want to recompile instead of deleting the .elc file. But then you also have to also manually change the last modification time to ensure that the .elc will not be considered newer than a changed .el at the next update. This starts getting tricky. Sincerely, Luc.