This is the mail archive of the
mailing list for the Cygwin project.
Re: LFTP: cygwin and setupterm
- From: Christopher Faylor <cgf-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 17 Dec 2002 01:17:56 -0500
- Subject: Re: LFTP: cygwin and setupterm
- References: <29950-220021221753745544@M2W028.mail2web.com>
- Reply-to: cygwin at cygwin dot com
On Tue, Dec 17, 2002 at 12:37:45AM -0500, email@example.com wrote:
>Just checked on both of my servers, they symlink /usr/include/term.h with
>ncurses/term.h, running RedHat 6.1 and 8.0. Should cygwin/ncurses do the
> The QNX proprietary term_* functions have been deprecated in favor of
> ncurses. ncurses is a set of terminal-independent routines for painting
> screens and handling input events......
> .....The file /usr/include/term.h is now an ncurses header file; you'll
> find the old <term.h> in /usr/include/sys/term.h. An error message is
> displayed if you combine the old term_* and ncurses header files.
Since the code clearly checks for the situation of finding the needed headers
in /usr/include/ncurses, I don't see any reason why this package should be
used as a justification for adding a symlink.
>Btw, I put the below __CYGWIN__ mention in because it still complained even
>when when it was passed the sufficient defines in CPPFLAGS and CXXFLAGS
>before running configure.
Usually when I see things like HAVE_NCURSES_CURSES_H, it suggests to me
that the author of the source code is correctly attempting to set things
up in a general, non-system-specific way and is testing for various
capabilities and oddities of the operating environment. System-specific
checks like "#ifdef ultrix" in source quickly become unmanageable.
That's why HAVE_NCURSES_CURSES_H is nice.
There's no reason why it couldn't work in this scenario. Of course, if it
"complained" maybe all you need to do is rebuke it sternly.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html