Ticket #12605 (new defect)
BUG: devel/ncurses does not provide libcurses and <curses.h>
| Reported by: | master@… | Owned by: | imajes@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | Port Bugs |
| Component: | ports | Version: | 1.5.0 |
| Keywords: | Cc: | imajes@…, mww@…, pipping@…, nox@… | |
| Port: |
Description
As of now, if an applications is trying to use curses "by the book", #include <curses.h> and -lcurses, then system (not macports) library is used, since libcurses symlink is not created in /opt/local/lib and curses.h is not in /opt/local/include.
But IMHO the whole idea of having both wide and not-wide ncurses is BAD. The bug report #6602 was complaining about incorrect _naming_ of libraries, but the fix brought us two sets of headers (wide being compatible extension of normal) and two sets of libraries (they are binary incompatible, but appications using non-wide API can be linked against wide libraries without modification). I think the better approach is that of Apple (as can be seen at http://www.opensource.apple.com/darwinsource/10.4.9.ppc/ncurses-15/Makefile ) - install wide version of ncurses as libncurses (without w suffix). The approach in the attached Portfile-new is even better
- install libncursesw and create symlinks libcurses and libncurses.
In this way we do not create a new portability obstacle, the canonical -lcurses works, and avoid extra work configuring/patching programs that for some reason want -lncurses or -lncursesw.
As a second-best solution I attach patches for two now existing Portfiles (ncurses and ncursesw), to put headers into /opt/local/include and make the libcurses symlink to libncurses. But in this case an application linking -lcurses and wishing to use wide API won't be happy.
The termcap-related additions are there to mimic how Apple configures system ncurses.

