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/[email protected]/msg15578.html
http://www.mail-archive.com/[email protected]/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"...
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
