[cmake-developers] Handling the NCurses fragmentation [yet another topic on this issue]

[Kamil Rytarowski]

Hello,

There is an old known problem with the NCurses library: missing links 
against ncursesw, and additionally ncursest with ncurseswt [1].

There is a bug report [2] marked as a backlog, with references to this 
mailing list [3].

I have built my Linux system with the wide-character NCurses library 
exclusively, without making backward compatibly links to the standard 
ncurses release, therefore I ended up with a problem against CMake 
(absence of ccmake etc) and finally against applications built with the 
support of CMake (FindCurses doesn't find the library). So, I had looked 
into the details.

1. There isn't that much difference between the flavours: ncurses and 
ncursesw, the headers of ncurses and ncursesw are nearly the same (there 
is mostly a slight difference with handling locales in the library)
2. ncursesw is simply the ncurses implementation - handling the 
discrimination on our will only increase cost of the maintaince of that 
single implementation [4]
3. If we add the support of ncursesw then we ran into troubles: what's 
up with the ncursest and ncurseswt flavours? Then we will produce all 
possible variations of include files:
curses.h
ncurses.h
ncursesw.h
ncursest.h
ncurseswt.h
curses/curses.h
curses/ncurses.h
...
...
...
ncurseswt/ncursest.h
ncurseswt/ncurseswt.h

including grown of the forwarded macro list...
#  CURSES_HAVE_CURSES_H - true if curses.h is available
#  CURSES_HAVE_NCURSES_H - true if ncurses.h is available
#  CURSES_HAVE_NCURSES_NCURSES_H - true if ncurses/ncurses.h is available
#  CURSES_HAVE_NCURSES_CURSES_H - true if ncurses/curses.h is available

and then manage relations, libraries, paths.. and so on... cost and trouble.

4. We cannot really guarantee that ncurses.h, neither curses.h is short 
nor ncursesw.h is wide. A library naming and install paths are only 
system specific, as far as I know many distros has switched to the 
wide-character version exclusively  and maintain the backward 
compatibility links curses.h -> ncurses.h -> ncursesw.h (the same as 
gawk points awk or lex points flex).
5. A developer is encourage to decide which type of curses use. This is 
doable using the predefined macros like [4] or NCURSES_WIDECHAR [5], 
overwritting default paths etc.

I am encouraging to close the bug [3] as "wont-fix", encourage everybody 
and every system to maintain the compatibility on its own. Personally, I 
won't harass Linus (a kernel config tool links just against -lcurses), 
and other projects against the ignorance of the fragmentation of the 
back-end library [6], I will simply add the missing links.

With kind regards,

[1] http://invisible-island.net/ncurses/ncurses.faq.html
[2] 
http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=10347&graph=relation
[3] http://www.mail-archive.com/cmake@cmake.org/msg15578.html 
http://www.mail-archive.com/cmake@cmake.org/msg27411.html
[4] NetBSD uses a single curses.h file and manages the wide extension 
through the macro defintion HAVE_WCHAR or DISABLE_WCHAR, what's up with 
Public Domain Curses (pdcurses), OpenBSD version etc?
[5] This easy doable with a specific implementation of a project 
CMakeLists.txt.
[6] And the last but not the least.. the ncurses project is built 
against a private, forked and uncompatible version of autotools... that 
is summarized as "a long story"...