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 08:33:49 +0300 Sender: emacs-devel-admin@gnu.org Message-ID: <7484-Wed17Apr2002083348+0300-eliz@is.elta.co.il> References: <87g01vbhzi.fsf@tc-1-100.kawasaki.gol.ne.jp> <1018986015.10524.108.camel@space-ghost> <1676-Wed17Apr2002000044+0300-eliz@is.elta.co.il> Reply-To: Eli Zaretskii NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1019022131 11579 127.0.0.1 (17 Apr 2002 05:42:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2002 05:42:11 +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 16xiCp-00030e-00 for ; Wed, 17 Apr 2002 07:42:11 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16xiVN-0000Vw-00 for ; Wed, 17 Apr 2002 08:01:21 +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 16xiCl-00088W-00; Wed, 17 Apr 2002 01:42:07 -0400 Original-Received: from mirapoint.inter.net.il ([192.114.186.20]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16xiB9-00085S-00; Wed, 17 Apr 2002 01:40:27 -0400 Original-Received: from zaretsky (diup-216-147.inter.net.il [213.8.216.147]) by mirapoint.inter.net.il (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id ABG06795; Wed, 17 Apr 2002 08:40:22 +0300 (IDT) Original-To: miles@gnu.org X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9 In-Reply-To: (message from Miles Bader on 17 Apr 2002 10:08:13 +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:2686 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2686 > From: Miles Bader > Date: 17 Apr 2002 10:08:13 +0900 > > 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. > 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. > > IMHO it doesn't make sense to go through all that just to save us the > > ``cost'' of a 25KB file. > > The `cost' is not 25KB, it's all the annoyance of constantly having to > fight with CVS getting confused because a file got regenerated locally > which then doesn't match the CVS version. In my case, this also ends > up making CVS updates take much longer because CVS ends up resending > all the `changed' files back to the server over my slooow connection. 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. I also doubt that the long update time you see will be significantly affected by excluding config.in. It's loaddefs.el that makes the difference. Yes, the CVS behavior whereby files are sent upstream if they are suspected to be different is a bug (I'm being hit by that twice a year, when the DST setting changes, because the Windows client doesn't DTRT wrt time stamps). But I've given up long ago on trying to convince CVS maintainers that some of their ``features'' are actually bad bugs, because I kept being told that I didn't understand ``the CVS spirit''. > the default should be > what's good for GNU systems, which are by far the majority among > developers. I _was_ talking about GNU systems; I build Emacs on fencepost regularly. I don't like to depend on the versions of the different auto-* tools installed by sysadmins--it could just happen that they fall out of sync, for example. I also build both trunk and branch, which use different Autoconf versions, so it's very easy to forget to run an older version of Autoconf manually before running configure. Now I will have to remember to run 2 commands by hand. I don't want that complication to ruin a release tarball some day. As another data point, the GDB development keeps all regenerated files in the CVS, including configure and even the Info files.