Re: Cone 0.57 now available.

[Thomas Dickey]

On Tue, 13 Jan 2004, Sam Varshavchik wrote:

> Thomas Dickey writes:
>
> > On Tue, 13 Jan 2004, Sam Varshavchik wrote:
> >> Cone's configure script relies on the compiler's default search path to 
> >> find
> >> include files, and stuff.  It doesn't lug around its own list of default
> >> directories to poke.
> >
> > It's going to have to get used to the notion that ncursesw's headers may
> > be in <ncursesw/xxxx> (and that there may be a /usr/include/curses.h
> > but /usr/local/lib/libncursesw.a which is unrelated).
>
> Well, at least two out of three are applicable for FC1.  The FC1 script only
> needs to do this:
>
> CPPFLAGS="-I /usr/include/ncursesw"
> export CPPFLAGS

yes - it happens to work since /usr/include is always in the include-path
(and because the headers include internally with <ncursesw/xxxx.h>.

If it were in /usr/local/include/ncursesw, depending on the platform you'd
have to ensure that /usr/local/include was in the include-path.

> That's it.  Fedora Core 1 puts narrowchar includes in /usr/include/ncurses,
> widechar includes in /usr/include/ncursesw, symlinks curses.h and ncurses.h
> to ncurses/curses.h, and puts both libraries in /usr/lib.
>
> I don't know if I should start assuming where things live.  Someone might
> decide to build a widechar-only curses, and put it in /usr/include.  I think
> it's much safer to stick to the compiler defaults and let people specify the
> directories themselves.

My head's running slow today - I finally focused on "Fedora".  What you're
describing is okay as far as it goes.  The curses.h generated for ncursesw
is a superset of the ncurses curses.h (I designed it that way so a
packager could overlay one on the other - though it's not done often since
it complicates uninstalling, etc).  Anyway I don't have any Redhat more
recent than Redhat9 for quick checking, and that was before ncursesw from
their standpoint.  (Some earlier packages broke includes of term.h by
leaving it alone in /usr/include/ncurses, while symlinking curses.h - I'm
curious if it's still fixed).

Anyway, to get the "right" header file, you're forced to do
compile-checking to see if representative wide-character functions are
present.  That's not just an issue with ncurses/ncursesw, but with
the vendor implementations (see the stuff I've put together in lynx
for an example of that).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net