Jeffrey Walton wrote: > > What trouble do you get? Portability problems? > > Fails to build on some platforms. Solaris is the latest casualty.
On Solaris, why not use '-lcurses' instead of '-lncurses'? > > So far, I'm not seeing a need. Ncurses is GNU, has regular releases, > > and supports most platforms nicely. When a package depends on it, I > > just install it. > > Ncurses has a lot of problems: > > 1. Governance. There's no public Git or SVN server hosting the code. > There is no way to submit patches against master because master is > hidden. You can download weekly snapshots at https://invisible-island.net/ncurses/#download_ncurses . That should be good enough. > There are no backup administrators if the maintainer gets hit > by a bus. A project can live on even if it had only one maintainer. For example, GNU Common Lisp lived on after William Shelter, its main developer, died. > Select patches are distributed piecemeal, and there's no way > to know if we are missing an important bug fix. That's not the impression I get. See above. > Project is hosted on a private server, and not a GNU property. Why would that matter, for the consumers of a GNU package? I find it equally dangerous to rely on packages hosted at github.com. > 2. Code quality. Awful, but this is my opinion. Trying to read the > Ncurses code is like trying to read GCC code. When I tried to track > down a memory leak, I found nearly everything was written in macros > that are stitched together to form a program. Macros are inevitable if you want to have the same code once with multibyte characters and once with wchar_t characters, without code duplication. > 3. Runtime execution. Leaks memory like a sieve. Impossible to test > with some tools. We can't differentiate the "good" memory leaks from > the "bad" memory leaks. Have you reported it? https://invisible-island.net/ncurses/ncurses.faq.html#report_bugs All your points, to me, are not a reason to question the use of ncurses on platforms where it compiles. Bruno
