ncurses vs ncursesw

[commodo]

[also sent on openwrt-devel mailing list, ncurses(w) is packaged in openwrt]

I'll try to get opinions about this.

Since we're in the middle of packages migration, maybe it's an interesting opportunity to try to use ncursesw and drop ncurses.

ncursesw is ncurses + Unicode (UTF8) support

Both libraries built out of the same source base, and they're just 2 build variants.
From what I can see, Midnight Commander may have some problems building with libncursesw, but I think those could be resolved.

python + python3 pick up libncursesw if they find it, but they could be configured to take libncurses
no idea about impact on other libs, hence this RFC

in the openwrt/packages folder there are only these libs that reference libncurses:

• deve/gdb
• utils/util-linux
• network/utils/iftop
• network/services/samba36

libncursesw is slightly fatter (360 kb) than libncurses (295 kb)
Having both installed on a device seems redundant, even though together the bloat is not too big.
So, then, what would be some opinions/prefs ?

Thanks
Alex

[Wedmer]

From README

If you configure using the --enable-widec option, a "w" is appended to the
library names (e.g., libncursesw.a), and the resulting libraries support
wide-characters, e.g., via a UTF-8 locale. The corresponding header files
are compatible with the non-wide-character configuration; wide-character
features are provided by ifdef's in the header files. The wide-character
library interfaces are not binary-compatible with the non-wide-character
version.

On most systems they're different packages.
For example in debian dev packages:
ncurses headers are in .../include
ncursesw headers placed at .../include/ncursesw

[commodo]

Well, I was hoping to get more feedback/ideas on this.

@Wedmer
I am aware that on most systems ncurses & ncursesw are different packages.

On OpenWRT, it's the same thing.
I was trying to see if there's an interest in making the ncursesw package the default, with the long-term intent of dropping the ncurses version.

Reason for this: I've seen a few issues during build, where if I just build the vanilla OpenWRT target + just python (which references the ncursesw package right now), there's a build failure, because the ncursesw build variant will be built, but the ncurses build variant won't be built, and util-linux will fail because there's no ncurses package [i.e. cannot find the ncurses headers, and the ncursesw headers are under include/ncursesw ].
[ All default OpenWRT system packages reference the ncurses build variant package ]

This is an issue with the build system, since both ncurses & ncursesw variants should be built.
I haven't made time yet to dig deeper into the cause, but I was thinking that there would be a few options:

1. convert all users of ncurses users to ncursesw
2. fix the build system to build both (adds bloat, but would be correct to do as well, since it may create other issues)

For the moment, I have a branch where I keep some work on converting the system packages to use ncursesw.
It's here: https://github.com/commodo/openwrt/commits/work
The biggest one to convert is devel/gdb; I'll have to clean it up.

Then maybe I'll try to assess what the effort would be to convert the current packages feed, and come up with a proposal.