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:10:21 -0400 Message-ID: References: <87y66fv2d3.fsf@stupidchicken.com> <4D388F7F.20708@swipnet.se> <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> <4D805B3F.1030900@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1300263038 18159 80.91.229.12 (16 Mar 2011 08:10:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Mar 2011 08:10:38 +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 09:10:33 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 1PzloO-0002fx-NT for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2011 09:10:33 +0100 Original-Received: from localhost ([127.0.0.1]:59928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzloM-0002f7-ST for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2011 04:10:30 -0400 Original-Received: from [140.186.70.92] (port=51582 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzloG-0002dW-Pj for emacs-devel@gnu.org; Wed, 16 Mar 2011 04:10:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PzloF-0003Ey-1g for emacs-devel@gnu.org; Wed, 16 Mar 2011 04:10:24 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:41038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PzloE-0003Eu-UZ for emacs-devel@gnu.org; Wed, 16 Mar 2011 04:10:23 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1PzloD-0008VU-NX; Wed, 16 Mar 2011 04:10:21 -0400 In-reply-to: <4D805B3F.1030900@cs.ucla.edu> (message from Paul Eggert on Tue, 15 Mar 2011 23:39:59 -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:137269 Archived-At: > Date: Tue, 15 Mar 2011 23:39:59 -0700 > From: Paul Eggert > CC: Glenn Morris , emacs-devel@gnu.org > > On 03/15/2011 10:53 PM, Eli Zaretskii wrote: > > It will be, if there's a practical way to know how to update the > > private config.in without having a Posix platform nearby. > > The same way you know now. Somebody sends email. > Or, perhaps Emacs doesn't build on MS Windows, and > the diagnostics reveal the problem. When that happens now, I can diff src/config.in against an older version. > Other possibilities include running GNU/Linux under a virtual > machine on a Windows machine; or running Autoconf and Automake > under Windows, and then generating config.in directly > on the Windows machine. Or one can grab a recent pretest > version. > > This is not an exhaustive list. > There are other simple and practical ways to address > this problem, which don't require putting > automatically-generated output into the repository. They are neither simple nor practical, sorry. I hope autoconf experts can come up with something that is simpler and more practical. Unfortunately, I cannot myself suggest anything, as I don't know enough about the machinery involved. > >> This would lessen the need for tight coupling between the mainline and > >> the DOS version. > > What "tight coupling"? > > Currently, when I edit files under src/ and src-lib/, > I often have to worry about porting to MS Windows or MS-DOS. And I need to worry about Posix platforms when I edit files in those same directories. So what? C is C and Lisp is Lisp and makefile.w32-in is just a Makefile. There's no magic about that. > There are many #ifdefs and similar constructs that complicate > the code, and are needed only because of the MS ports. There are ifdefs because of Solaris as well. So what? We try to keep them to the absolute minimum, and when someone points out to one of them that is used by DOS alone, I'm always happy to move it away in any reasonably practical way. > It would be better if this porting code were isolated > to the msdos/ and nt/ directories, so that developers > under GNU and GNUish systems did not have to look at it > or worry about it. It is already done, as much as is practical. > The src/config.in file is one example of these #ifdef-like > constructs. The main reason we put src/config.in in the > repository, and keep track of it and commit it by hand, > is for the MS Windows port. It was never because of MS-DOS. This file was there from day one. This is the first time removal of this file is considered. Until now it was used by every platform. > If we can think of another way to handle this, it would save us > work. Fine with me, but please try to be less unkind to maintainers of non-Posix platforms. They are volunteers like yourself. If there's a reasonable way of gleaning the information about the added and removed #defines in src/config.in, I will be the first to embrace it. What you suggested until now is unreasonable. > Moving src/config.in to msdos/config.in is one way to do that. > It may require a bit more work on the part of the Windows > developers, but it'll require less work from the rest of us, > and overall it will be a win. A shockingly egotistic position. MS-Windows is my main development platform for working on the bidirectional editing support. Maybe you will also claim that bidirectional editing is not needed by "the rest of us", so my work on that is not important.