From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A better autogen.sh Date: Wed, 16 Mar 2011 06:37:32 -0400 Message-ID: References: <87y66fv2d3.fsf@stupidchicken.com> <87r5c7jk5m.fsf@stupidchicken.com> <4D39EF9C.1050804@cs.ucla.edu> <4D3A8666.4070609@cs.ucla.edu> <877hdvd49f.fsf@meyering.net> <83mxmrzhb6.fsf@gnu.org> <4D3C9C5B.8050303@cs.ucla.edu> <4D7FDFB0.6020203@cs.ucla.edu> <4D7FEF16.7040107@cs.ucla.edu> <8362rjr9po.fsf@gnu.org> <4hk4fzsnv8.fsf@fencepost.gnu.org> <4D80817D.2070805@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1300272317 2383 80.91.229.12 (16 Mar 2011 10:45:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Mar 2011 10:45:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 16 11:45:12 2011 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 1PzoDx-0004iI-NY for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2011 11:45:11 +0100 Original-Received: from localhost ([127.0.0.1]:41795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzoDq-0003hK-24 for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2011 06:44:58 -0400 Original-Received: from [140.186.70.92] (port=43919 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pzo7G-0006jM-3T for emacs-devel@gnu.org; Wed, 16 Mar 2011 06:38:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pzo6g-0000tC-BS for emacs-devel@gnu.org; Wed, 16 Mar 2011 06:37:36 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:45277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pzo6g-0000t2-9v for emacs-devel@gnu.org; Wed, 16 Mar 2011 06:37:34 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Pzo6e-0000dm-PS; Wed, 16 Mar 2011 06:37:32 -0400 In-reply-to: <4D80817D.2070805@cs.ucla.edu> (message from Paul Eggert on Wed, 16 Mar 2011 02:23:09 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:137275 Archived-At: > Date: Wed, 16 Mar 2011 02:23:09 -0700 > From: Paul Eggert > CC: Glenn Morris , emacs-devel@gnu.org > > On 03/16/2011 01:47 AM, Eli Zaretskii wrote: > > The trouble is, we keep requiring newer versions of autoconf from time > > to time, and later more frequently than in the past. Experience shows > > that upgrading autoconf on fencepost involves asking GNU sysadmins to > > do that, which takes a non-trivial amount of time and sometimes > > repeated pinging. > > That may have been a problem in the past, but it's not a problem now, > because fencepost's /usr/bin/autoconf is Autoconf 2.65, which > is good enough for Emacs. > > In the long run I don't expect this to be a major issue, > but if I'm wrong, I can volunteer to keep > good-enough versions of automake and autoconf installed on > fencepost, under ~eggert/bin say, and that will be enough to > get it to work. Thanks, but I don't think it is practical to make the maintenance of non-Posix platform depend on people who are not interested in Emacs running on those platforms. Could you please instead tell if new and modified #define's in config.in can be detected by grepping certain files for AC_DEFINE or similar directives, and which files to grep? If it is possible to specify which files to grep for what patterns, that would open a way for a practical maintenance routine of config.in outside the main directories of the Emacs tree, and we could then put this issue to rest (until the next time, which will doubtlessly come).