From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.devel Subject: Re: configure{.in,} question Date: Sun, 24 Oct 2010 16:07:36 -0400 Message-ID: <09k4l72w3b.fsf@fencepost.gnu.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1287951981 7605 80.91.229.12 (24 Oct 2010 20:26:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Oct 2010 20:26:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 24 22:26:20 2010 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.69) (envelope-from ) id 1PA791-0002Dd-N1 for ged-emacs-devel@m.gmane.org; Sun, 24 Oct 2010 22:26:19 +0200 Original-Received: from localhost ([127.0.0.1]:33843 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PA790-0006vg-Nn for ged-emacs-devel@m.gmane.org; Sun, 24 Oct 2010 16:26:18 -0400 Original-Received: from [140.186.70.92] (port=55812 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PA74L-0003lr-Ed for emacs-devel@gnu.org; Sun, 24 Oct 2010 16:21:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PA6qu-0004Rw-Ic for emacs-devel@gnu.org; Sun, 24 Oct 2010 16:07:37 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:60196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PA6qu-0004Rs-Fj for emacs-devel@gnu.org; Sun, 24 Oct 2010 16:07:36 -0400 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PA6qu-00043G-5B; Sun, 24 Oct 2010 16:07:36 -0400 X-Spook: Downing Street Juiliett Class Submarine USCOI X-Ran: /UMR[$I\0MBXTO)>KGaeCUUsZdc@Syxr-=4,jBr&WI'TZ6gxCa8.ODfo4Z%t^34;B/k^l] X-Hue: blue X-Attribution: GM In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun\, 24 Oct 2010 21\:56\:26 +0200") User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:132067 Archived-At: Lars Magne Ingebrigtsen wrote: > Hm. This line didn't change when I ran autoconf: > > # Generated by GNU Autoconf 2.65 for emacs 24.0.50. I don't know why you would get a "somewhat big" diff then, but don't worry about it. Maybe nobody regenerated configure for a while. Or sometimes eg Debian seems to have local patches to autoconf so that their version behaves a bit differently to others with the same version number. > So... I should just commit this, even though this has nothing to do > with the change I was making in configure.in? Sure. Just describe it as "regenerate configure". I have wondered whether configure even needs to be in the repository. Here is something I wrote once but never bothered to send till now: configure should be included in release tarfiles, but should it be kept in the repository, or should just configure.in be there? Problems causes by keeping configure in the repository: 1) Need for developers to regenerate it and check it in. 2) Often leads to large, meaningless diffs. For example, the merge of the imagemagick branch had a diff of about 2500 lines. 1500 lines of this were configure, and so totally meaningless. Different developers using different versions of autoconf to generate configure often leads to large diffs that bury the real change to configure.in amongst noise. It's lead to the situation where AC_PREREQ is artificially high, simply to try to stop this. I don't think this is a good solution. 3) More problems with merges between branches, I imagine. 4) People in the habit of running autoconf are likely to end up with conflicts when configure is updated. 5) ... ? Advantages to keeping configure in the repository: 1) People don't need autoconf installed. I think this is a small advantage, since autoconf is commonly present and easy to install. 2) The configure script gets more thorough testing (if is generated by developers with a fixed version of autoconf and people don't regenerate it). 3) ... ?