[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 MarcusCalhoun-Lopez):

 Just to refine my analysis:
 * Minimal reproducible error
  * `echo "#import <sys/types.h>" | env CPATH=/opt/local/include clang
 -xobjective-c -c -fmodules -v -o test.o -`
  * `echo "import Darwin" | env CPATH=/opt/local/include swiftc -v -o
 test.o -`
 * The problem happens **only** during the generation of the module cache.
  * Once the cache files are generated (see `-fmodules-cache-path=...`),
 subsequent compilations work fine.
  * The specific cache directory seems to depends on quite a few variables.
   * MACOSX_DEPLOYMENT_TARGET
   * DEVELOPER_DIR
   * SDKROOT
   * `-O`
 * The problem happens with the reading of
 `/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/module.modulemap`.
  * `module Darwin` has a submodule `explicit module ncurses`, which has a
 submodule `explicit module unctrl`.
  * ncurses has a circular include dependency.
   * `ncurses.h` includes `unctrl.h`
   * `unctrl.h` includes `ncurses.h`
   * Newer versions of ncurses have changed exactly how these two files
 interact.
  * `module.modulemap` does not seem to have a mechanism to handle circular
 dependencies.

 Here are some possible solutions/workarounds:
 1. Patch Clang
  * If the circular dependencies are a fundamental issue. there is nothing
 to be done.
  * Any changes would take quite a while (if ever) to reach Xcode clang.
  * Almost certainly, Clang upstream help would be required.
 1. Patch `uncntrl.h` to remove `SCREEN`.
  * We would be removing expected functionality to facilitate the
 ''generation of cache files''.
  * We would forever be responsible for making sure `uncntrl.h` continued
 to work.
 1. Patch `uncntrl.h` to minimize the effect of the circular dependency.
  * It is not clear yet how this could be accomplished.
  * We should have to work with ncurses upstream to get any changes merged.
 1. Generate required cache files **before** building the port (e.g. during
 `post-extract`).
  * I was able to accomplish this with the port topgrade.
  * A PortGroup could accomplish this with some effort.
  * It is **very** fragile since the cache directory name is highly
 dependent on the compiler settings.
 1. Attempt to get ncurses to work within the modules infrastructure.
  * There is a [https://github.com/macports/macports-ports/pull/6737 pull
 request] to that effect.
  * I am not 100% sure why this works or how fragile it is.

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