emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO additions


From: Dave Love
Subject: Re: TODO additions
Date: 27 Nov 2002 23:38:22 +0000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Richard Stallman <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]