[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 jmroot):

 If you're having trouble understanding the issue, I'll try to explain it
 in more generic terms. Suppose you have a pair of headers foo.h and bar.h,
 and they exist in both /usr/include and /usr/local/include. The pair in
 each location is designed to work together, but using one header from one
 location and the other header from the other location won't work for
 whatever reason (the possibilities are endless really).

 Now further suppose each foo.h contains a line `#include <bar.h>`. Now
 consider a C program baz.c that starts like this:

 {{{
 #include <foo.h>
 ...
 }}}

 When compiled, the preprocessor will looks for foo.h in its search paths.
 /usr/local/include comes first, so it will use /usr/local/include/foo.h.
 While processing that file, it will see `#include <bar.h>`, and go through
 the same process to find that file, again using the one in
 /usr/local/include. Everything works fine.

 But consider if you change baz.c to this:
 {{{
 #include </usr/include/foo.h>
 ...
 }}}

 Now the preprocessor will load /usr/include/foo.h because it is specified
 with an absolute path. While processing foo.h, it will again see `#include
 <bar.h>`, and find bar.h in /usr/local/include because that location is
 first in the list. Oops, the headers aren't compatible and the program
 breaks.

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