Closed mieko closed 7 years ago
Hi, thanks - this looks good, and I just merged it to master.
-gaute
Thanks, @gauteh.
Is there anything I can do to help get out a 1.4.10 gem release with the last few years of build fixes? E.g., testing the build on not-current (~6 years) Unixish platforms, etc? Version update PR?
Mike Owens writes on august 2, 2016 14:07:
Thanks, @gauteh.
Is there anything I can do to help get out a 1.4.10 gem release with the last few years of build fixes? E.g., testing the build on not-current (~6 years) Unixish platforms, etc? Version update PR?
Yes, that would be great! I am not currently using sup anymore so I don't have a test setup at hand. If you make a PR with the necessary changes for a release I would be happy to push the new gem.
Hey, sup team. I really appreciate you guys grabbing the torch with ncursesw-ruby.
It's apparently becoming a thing for systems to only provide libncurses.so, but built with wide support. macOS is now one of these, so ncursesw-ruby doesn't build. This is distinct from the case where libncurses.so is built with wide character support, and libncursesw.so is a symlink to it. They don't have a libncursesw.so at all.
This change to the build detects if 'libncurses' has wide functionality, and uses it if so. It also assumes libform was built wide if libncurses was, which is also required to build on Darwin.
I've got an application that now has to depend on 'ncurses-ruby' on macOS and 'ncursesw' on other platforms to get wide character support. 'ncursesw' building on stock macOS again would let me get off of that fork and standardize on ncursesw.
Edit: package tested on Ubuntu 16.10.1 and macOS 10.12 preview.