[MacPorts] #59992: ncurses at 6.1 : /opt/local/include/unctrl.h:60:63: error: unknown type name 'SCREEN'

[MacPorts]

#59992: ncurses at 6.1 : /opt/local/include/unctrl.h:60:63: error: unknown type name
'SCREEN'
----------------------+----------------------
  Reporter:  kencu    |      Owner:  jmroot
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:
Resolution:           |   Keywords:
      Port:  ncurses  |
----------------------+----------------------

Comment (by kencu):

 Anything that uses Xcode clang and modules is broken in MacPorts by
 ncurses. Modules are a newer feature, so penetrance is evolving. I
 manually delete the libtapi tests that use modules, so you wouldn't see
 it. Proper clang-devel builds now want modules, and fail in MacPorts
 because of ncurses. Sure, perhaps I could disable modules project-by-
 project. I'm just not going to do that.

 google this "error: unknown type name 'SCREEN'" for hits on other
 projects. Those hits usually lead to a suggestion much like you did
 "disable macports headers".or "uninstall macports". That's not a great
 solution.

 I have have tweaked my MacPorts unctrl.h to work around this, as at
 present that is the only solution I know of, other than disabling
 MacPorts, that generally works.

 We can talk about the purity of working around a clang issue by tweaking
 ncurses --- it's not a pure fix, I know .

 But neither is unsetting CPATH and the library path, or disabling module
 support, or the parts of projects that require modules. We'll have to go
 back and undo all those hacks when clang is fixed too, and IMHO those are
 much more impactful than tweaking unctrl.h until Apple figures this out.

 Or perhaps you can fix the clang issue, Marcus. If we could do that, all
 this would go away in a proper fashion.

-- 
Ticket URL: <https://trac.macports.org/ticket/59992#comment:26>
MacPorts <https://www.macports.org/>
Ports system for macOS