As you’ve realised, the confusion comes from mixing up ncurses 5 from the macOS SDK and ncurses 6 from another source (MacPorts/conda/whatever).
The include is coming from rootcling parsing $SDKROOT/usr/include/module.modulemap which contains:
explicit module ncurses {
header "ncurses.h" // note: same as curses.h
export *
explicit module dll {
header "ncurses_dll.h"
export *
}
explicit module unctrl {
textual header "unctrl.h"
}
}
For some reason (which Vasil thinks is a clang 5 bug) ncurses.h is being taken from $SDKROOT/usr/include/ncurses.h while unctrl.h comes from other ncurses installation (in this case /opt/local/include/unctrl.h).
My horrible hack in conda-forge for this is to use sed to edit the SDK and modify header "ncurses.h" to be header "/path/to/conda/prefix/include/ncurses.h". I do not recommend it but it’s a good enough temporary hack for conda-forge as VM is destroyed after each build but it’s probably not an option for anyone else.
Alternatively, it’s possible to avoid this issue by modifying ROOT’s CMake configuration to avoid adding unneeded include paths in the call to rootcling when linking G__Core. These aren’t needed and come from here and will (in the case of MacPorts) result in -I/opt/local/include/ being added to the rootcling_stage1 command up to 4 times. Manually editing the text file to remove these includes avoids the bug I haven’t tried to get CMake to generate the command correctly.