From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: TODO additions Date: 27 Nov 2002 23:38:22 +0000 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200210291902.g9TJ2AY18220@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1038440478 31082 80.91.224.249 (27 Nov 2002 23:41:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 27 Nov 2002 23:41:18 +0000 (UTC) Cc: schwab@suse.de, monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18HBnv-000859-00 for ; Thu, 28 Nov 2002 00:41:15 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18HBuj-0003Ip-00 for ; Thu, 28 Nov 2002 00:48:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18HBma-0005Sv-00; Wed, 27 Nov 2002 18:39:52 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18HBlI-0002DX-00 for emacs-devel@gnu.org; Wed, 27 Nov 2002 18:38:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18HBlE-00025C-00 for emacs-devel@gnu.org; Wed, 27 Nov 2002 18:38:30 -0500 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18HBlB-0001x6-00; Wed, 27 Nov 2002 18:38:26 -0500 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 18HBl8-0004kE-00; Wed, 27 Nov 2002 23:38:22 +0000 Original-To: rms@gnu.org Original-Lines: 70 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9714 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9714 Richard Stallman writes: > The question was about libc for Linux, not about Emacs on Debian. > > I didn't realize that, but the answer is the same: maybe we > should put some of those patches into the standard version. I don't know whether this means Emacs or libc. If the latter, as far as I know, there aren't Debian-specific patches. The current set of diffs for Emacs does appear to suggest that mail locking will get configured wrongly on Debian, and you could lose mail. I don't understand this offhand -- I originally put in autoconf tests which I thought were consistent with the then-current Debian changes. [I'm actually using the XEmacs movemail from Debian, not the vanilla one, because my mail spool isn't fed by a Debian system and I need to be able to set the locking appropriately. I did look at merging those changes, since they're probably covered by assignments, but it wasn't straightforward. Doing that, or making equivalent changes, should be in TODO.] For 21.3, you might want other changes for gnu-linux mipsle, hp and s390 targets, but they're inconsistent with the treatment in the current head sources. (I just made a trivial change which should get mipsle OK.) I can send a pared-down version of the diffs if that's useful. > It's actually GNU libc for GNU/Linux. Please don't call the whole > system "Linux", I'm not. I'm referring to one of the two kernels the library currently supports, like node `Linux' in the libc manual. > I don't see why these macro definitions would be any shorter > if they were copied into configure.in. I'm talking about doc strings for them (which can't be copied if they don't exist). > I don't know what you mean. The information I'm talking about is just > missing. > > Precisely what information are you talking about, then? What macros _mean_. Consider some of the things used in systty.h: BSD_TERMIOS, HAVE_TCATTR, HAVE_TERMIO, NO_TERMIO, HAVE_TERMIOS. Does HAVE_TERMIOS mean _POSIX_ termios? When should HAVE_TERMIO, NO_TERMIO be defined? That sort of thing. > I thought your proposal was to specify directly in > configure.in the values that are now specified in > the s/ and m/ files. I didn't say that. I'd want to avoid specifying as much as possible. E.g. autoconf has AC_SYS_POSIX_TERMIOS, and I can detect termio.h &c, but without information like the above, that doesn't help. > > The inheritance chains of *.h files are often long. Perhaps it would > > simplify matters in some situations to eliminate some of the inheritance > > by making some of the files self-contained. > > That would be better. > > Would you like to propose specific files to change so that they > do not inherit? I'll try to later.