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 04:47:06 -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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1300265252 29222 80.91.229.12 (16 Mar 2011 08:47:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Mar 2011 08:47:32 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 16 09:47:28 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 1PzmO4-000879-AR for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2011 09:47:24 +0100 Original-Received: from localhost ([127.0.0.1]:53017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzmO3-0004mX-9G for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2011 04:47:23 -0400 Original-Received: from [140.186.70.92] (port=48792 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzmNp-0004kk-Hz for emacs-devel@gnu.org; Wed, 16 Mar 2011 04:47:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PzmNn-0008EN-Nx for emacs-devel@gnu.org; Wed, 16 Mar 2011 04:47:08 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:42259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PzmNn-0008EJ-MO for emacs-devel@gnu.org; Wed, 16 Mar 2011 04:47:07 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1PzmNm-0004Yw-5I; Wed, 16 Mar 2011 04:47:06 -0400 In-reply-to: (message from Glenn Morris on Wed, 16 Mar 2011 02:43:10 -0400) 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:137270 Archived-At: > From: Glenn Morris > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Wed, 16 Mar 2011 02:43:10 -0400 > > Eli Zaretskii wrote: > > > How would I know that a change needed, and (more importantly) how > > would I know what to update there? > > I assume you at least have access to a POSIX platform, eg fencepost, > where you can run autoconf once in a while. What would you or other maintainers say if I suggested a change that would require them to log in to a remote system each time they wanted to build the latest trunk, generate some file there, then copy it to their local machine? How can a member of a team even suggest something like that to another member? > > nt/config.nt is maintained by hand, allright, but that's done by > > tracking changes in src/config.in. If src/config.in is removed from > > the repository, maintaining nt/config.nt will hit a snag, because > > there will be no file to "bzr diff" against the previous version and > > see what's changed, and how else would someone know how to update > > config.nt? > > Whenever an AC_DEFINE is changed in configure.in, config.in might need > to be changed. I don't think this is enough. Don't other m4/* files contribute to config.in eventually? If I'm mistaken and it's all in configure.in, this could be an okay alternative. Even if it's not only in configure.in, but grepping for AC_DEFINE in *.m4 files is all that's needed, that would be good enough to make this a reasonable way of maintaining the Windows and DOS config.h files. I hope some autoconf expert could tell one way or the other. > >> > autogen.sh could begin by removing config.in. > >> > >> That's a bit ugly > > > > Why ugly, move-if-change should be fine. What am I missing? > > It's ugly because then everybody has a src/config.in file that appears > to be locally modified all the time. I don't see why it will appear modified, if its content is identical. bzr is smart enough to not flag such files as modified. Or am I missing something? > > It will be, if there's a practical way to know how to update the > > private config.in without having a Posix platform nearby. > > I hope it's not unreasonable to assume the MS-DOS maintainer can access > a POSIX platform once in a while. I rather hope this will not the way, because it _is_ unreasonable, both in practical terms and in its underlying attitude, which frankly is revolting. > If it were me, I'd keep the same version of autoconf installed. I'd run > it periodically and diff the generated src/config.in against > msdos/config.in. If there was a difference, I'd copy the former to the > latter and commit it. 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. I would like to avoid that, because it will make my life as Emacs developer miserable. Likewise with other contributors to the maintenance of the Windows port (I don't think they even have a fencepost account, btw). > But I hope src/config.in doesn't have to be kept just for the sake > of MS. Me too, but it will take someone with working knowledge of the machinery involved and a friendly attitude to help resolve this in a way that we all can live with.