Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: ZSH (CVS) configure problem?
- X-seq: zsh-workers 23940
- From: Clint Adams <schizo@xxxxxxxxxx>
- To: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
- Subject: Re: ZSH (CVS) configure problem?
- Date: Thu, 11 Oct 2007 16:23:08 -0400
- Cc: Zsh hackers list <zsh-workers@xxxxxxxxxx>
- In-reply-to: <200710111918.l9BJI33N021057@xxxxxxxxxxxxxxxxxxx>
- Mail-followup-to: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20071011182853.GA19842@xxxxxxxxxxx> <200710111918.l9BJI33N021057@xxxxxxxxxxxxxxxxxxx>
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