From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: config.in Date: Wed, 17 Apr 2002 05:22:32 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <87g01vbhzi.fsf@tc-1-100.kawasaki.gol.ne.jp> <1018986015.10524.108.camel@space-ghost> <1676-Wed17Apr2002000044+0300-eliz@is.elta.co.il> <7484-Wed17Apr2002083348+0300-eliz@is.elta.co.il> Reply-To: Eli Zaretskii NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1019035538 28888 127.0.0.1 (17 Apr 2002 09:25:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2002 09:25:38 +0000 (UTC) Cc: walters@verbum.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16xlh3-0007Vi-00 for ; Wed, 17 Apr 2002 11:25:37 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16xlzg-0005Yr-00 for ; Wed, 17 Apr 2002 11:44:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16xlfb-0002mr-00; Wed, 17 Apr 2002 05:24:07 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 3.34 #1 (Debian)) id 16xle4-0002k4-00; Wed, 17 Apr 2002 05:22:32 -0400 Original-To: miles@gnu.org In-Reply-To: (message from Miles Bader on 17 Apr 2002 14:54:35 +0900) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2690 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2690 > From: Miles Bader > Date: 17 Apr 2002 14:54:35 +0900 > > > > Note that even if these generated files are included, they may _still_ > > > need the auto* programs, because CVS makes no attempt to preserve > > > timestamps, and the Makefile will attempt to regenerate the files > > > anyway (though the checked-out contents are actually `up to date'). > > > > This can be handled with a simple call to `touch', if it turns out to > > be a real problem. > > That is an annoying and error-prone method of dealing with the problem > (and yes, it's a problem, that's why this issue keeps coming up); more > often than not, by the time you realize something's amiss, it's too > late, and CVS has screwed up the file by inserting conflict markers. > > Morever, such a solution is _certainly_ not something that you'd > recommend to clueless users; it's easier to tell them to install > autoconf! You misunderstood me--or rather, I didn't explain well enough what I meant. I didn't mean to suggest a manual `touch'. The idea was to put something into the configury which will do that automatically, assuming we can detect time stamp mismatches that are produced by CVS. > However, if we remove configure from CVS, then we should be consistent > and remove the other autoconf generated files too, since they don't > require any additional tools. Yes, I agree that we should be consistent here. > > As another data point, the GDB development keeps all regenerated > > files in the CVS, including configure and even the Info files. > > That is their decision (though I wouldn't be surprised if exactly this > same flame war pops up periodically on their mailing lists). FWIW, I'm reading their lists for the last couple of years, and I don't remember any complaints.