Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: ZSH (CVS) configure problem?



On Thu, Oct 11, 2007 at 08:18:03PM +0100, Peter Stephenson wrote:
> On my system the entire contents of /usr/include/ncurses (which it seems
> to be well-established we don't need to add to the search path) are
> simply links into /usr/include/ncursesw.

This is the current state of Debian:

The left column is ncurses compiled without --enable-widec , and the
right is ncursesw (--enable-widec).

% paste <(dpkg -L libncurses5-dev | grep 'include.*h') <(dpkg -L libncursesw5-dev | grep 'include.*h')
/usr/include/unctrl.h   /usr/include/ncursesw/unctrl.h
/usr/include/termcap.h  /usr/include/ncursesw/termcap.h
/usr/include/cursesp.h  /usr/include/ncursesw/cursesp.h
/usr/include/curses.h   /usr/include/ncursesw/curses.h
/usr/include/tic.h      /usr/include/ncursesw/tic.h
/usr/include/eti.h      /usr/include/ncursesw/eti.h
/usr/include/nc_tparm.h /usr/include/ncursesw/nc_tparm.h
/usr/include/cursesw.h  /usr/include/ncursesw/cursesw.h
/usr/include/term_entry.h       /usr/include/ncursesw/term_entry.h
/usr/include/form.h     /usr/include/ncursesw/form.h
/usr/include/cursesm.h  /usr/include/ncursesw/cursesm.h
/usr/include/menu.h     /usr/include/ncursesw/menu.h
/usr/include/cursesapp.h        /usr/include/ncursesw/cursesapp.h
/usr/include/cursesf.h  /usr/include/ncursesw/cursesf.h
/usr/include/cursslk.h  /usr/include/ncursesw/cursslk.h
/usr/include/panel.h    /usr/include/ncursesw/panel.h
/usr/include/etip.h     /usr/include/ncursesw/etip.h
/usr/include/term.h     /usr/include/ncursesw/term.h
/usr/include/ncurses_dll.h      /usr/include/ncursesw/ncurses_dll.h
/usr/include/ncurses.h  /usr/include/ncursesw/ncurses.h

I've heard some vague promises that the ncursesw packages will disappear
and that we'll have only the --enable-widec headers and libraries in
libncurses$num-dev.  If there are no ABI issues with this, I'd prefer it
happens as soon as possible.

> Shall we try this?  I'd be interested to see how it works out.
> If we end up not compiling in multibyte support, should be replacing
> ncursesw with ncurses, or is that unnecessary?

Given my current understanding, if both ncurses{,w} -dev packages
installed, this will link against the wide library but use the non-wide
macros.  I assume this is harmless and equivalent to just linking
against the non-wide library.



Messages sorted by: Reverse Date, Date, Thread, Author