From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: config.in Date: 17 Apr 2002 14:54:35 +0900 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: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019023030 12681 127.0.0.1 (17 Apr 2002 05:57:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2002 05:57:10 +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 16xiRK-0003IQ-00 for ; Wed, 17 Apr 2002 07:57:10 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16xijs-0000tk-00 for ; Wed, 17 Apr 2002 08:16:20 +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 16xiRM-0000KI-00; Wed, 17 Apr 2002 01:57:12 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16xiPC-0000FP-00; Wed, 17 Apr 2002 01:54:58 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g3H5sgd12025; Wed, 17 Apr 2002 14:54:42 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g3H5sdL03179; Wed, 17 Apr 2002 14:54:39 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g3H5saB11816; Wed, 17 Apr 2002 14:54:38 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g3H5sZg01909; Wed, 17 Apr 2002 14:54:35 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 6DD6837C8; Wed, 17 Apr 2002 14:54:35 +0900 (JST) Original-To: Eli Zaretskii System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <7484-Wed17Apr2002083348+0300-eliz@is.elta.co.il> Original-Lines: 49 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:2688 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2688 "Eli Zaretskii" writes: > > Anyone who checks emacs out of CVS is basically not a normal user, > > and it's perfectly reasonable to expect them to have normal GNU > > tools. > > IMHO, those requirements should be kept at the minimum, and that this > should be a factor in our decisions, not something rejected off hand. I agree -- but only a factor, and a secondary one. > > 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! > I was talking about config.in alone, not about the other generated > files. I don't have anything against removing other generated files > we've discussed here, since they all are made during the build by > running Emacs Commands. The _main_ problem is `configure', which is generated by autoconf. 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. > 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). The tradeoffs are not necessarily the same in every situation. -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research