Build only wide character library variants

[mbargull]

But still provide symlinks for w for backward compatibility.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

closes gh-21

NOTE: This is not yet tested and marked as draft to be merged (if acceptable) only after the holidays.

refs:

• Update to Python 3.12.1 python-feedstock#656 (comment)

• Homebrew has symlinks from non-*w pointing to *w libraries:
  • https://github.com/Homebrew/homebrew-core/blob/24808e755b8005b39c59029507e9a43d4e5a8296/Formula/n/ncurses.rb#L65
• MacPorts have symlinks from *w poiting to non-*w libraries:
  • https://github.com/macports/macports-ports/blob/703e76e8f90d7fb0837b315cf414b4175b61fbbb/devel/ncurses/Portfile#L36
  • https://github.com/macports/macports-ports/blob/703e76e8f90d7fb0837b315cf414b4175b61fbbb/devel/ncurses/Portfile#L68
• Fedora- and Debian-based distributions seem to have separate non-*w libraries, i.e., without wide char support like conda-forge::ncurses.
• Arch Linux-based distributions use linker scripts for non-*w libraries pointing to the *w ones
  • https://gitlab.archlinux.org/archlinux/packaging/packages/ncurses/-/blob/3c2606603aa4a5a3b2d29e560a1bc14986153f49/PKGBUILD#L74

I don't know what (if any) downsides there are to not having the wide character supported merged in to the non-*w named libraries.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ismail]

This should be macOS only imho, on Linux it's normal to have non-wide and wide versions side by side.

[mbargull]

This should be macOS only imho, on Linux it's normal to have non-wide and wide versions side by side.

No, we have a heterogeneous landscape, see OP.
Most have separate non-wide variants, but some, e.g., Arch- or Nix-based do not.

For conda-forge it makes sense to look for homogeneity in its packages.
If there are no downsides in providing wide chars symbols in non-w libraries, then having separate libraries is just added complexity without benefit.

That said, I expect this to be carefully reviewed (e.g., ensure all non-wide symbols are properly exported, etc.).

[mbargull]

Linux builds didn't like to have libncursesw -> libncurses links, so I switched this around to be libncurses -> libncursesw.
This in turn makes the layout similar to

• https://github.com/Homebrew/homebrew-core/blob/24808e755b8005b39c59029507e9a43d4e5a8296/Formula/n/ncurses.rb
• https://gitlab.archlinux.org/archlinux/packaging/packages/ncurses/-/blob/3c2606603aa4a5a3b2d29e560a1bc14986153f49/PKGBUILD
• https://github.com/NixOS/nixpkgs/blob/5ac7bc5197516267524bfc740456f700867745fb/pkgs/development/libraries/ncurses/default.nix

There are some more subtleties we'd want to iron out (e.g., only link main headers into top-level include?, replace some symlinks with linker scripts?, tinfo handling, build shared library for c++ binding?).