I can't import MacPorts' /opt/local/include/ncurses.h into my Swift project. It conflicts with macos SDK /usr/include/ curses.h. Any hint?

Question

EDIT: Getting negatives for such a detailed and HONEST question? Sometimes I don't really get Stack Overflow. Really.

---

Hi, I'm trying to create a PoC using Swift 5 (Xcode 10.2.1) and a modern rendition of ncurses (in this case, MacPorts' one, some 6.1.2018XXXX version)

My Poc has no code as of now, as my problems start before being able to add any sensible line to my .swift files.

So far I've done the following things:

1.- I have a proper working MacPorts ncurses library installed: that means "sudo port install htop" can build "htop" application without any problem, proving that way that my ncurses library is correctly installed (.h files seem to be deployed inside /opt/local/include/ directory)

2.- I create an empty CONSOLE APPLICATION swift program (using Xcode 10.2.1 own wizard). It just takes 4 mouse clicks, and you get some "Hello world" silly main.swift file.

3.- I create a bridging header to import my .h files (in this case ncurses.h). The contents of this bridging header will/should be something like this:

#import "/opt/local/include/ncurses.h"

4.- I compile and run the silly empty "hello world" swift program, and I get tons of somewhat "expected" errors. Something like: "Darwin/SDK curses.h symbol xxxxxxxxx is also defined inside your /opt/local/ncurses.h file. Bailing out." (it's not the literal error I get, you just get the idea)

So my question is:

Can I disable/remove Darwin/internal/MacOs SDK curses.h from my XCode project definition somewhere, in order my bridging header only sees one copy of my 2 (n)curses.h file (that should be my macports one)?

I've tried many things described in this other thread, but with no luck: How to disable "curses.h" header (a part of "stdio.h in Xcode 6.3 OSX Yosemite) to avoid conflicting function declarations

Specially "Enable Modules" option, which no matter the value you set it to, seems to do nothing.

BTW: I know when I might solve this .h headers issue, I will probably need to add some additional -lib linking option in the "build phase"(?) tab inside Xcode, but I'll try to manage myself when that moment arrives.

As of now my concern is "I wan't to remove Apple Internal Macos SDK curses support/files from my Xcode project". Is it achievable?

PS: I'm using Mojave 10.4.4 with no problem

Vomitory

Answer 1

I'm having the same issues, although trying to use ncurses via the Swift Package Manager. Despite being actively trying to find a solution I've been unsuccessful so far. Check my question just in case: Swift package manager unable to compile ncurses installed through Homebrew

Mongol

Answer 2

This answer should give you all the information you need to get it working :) https://mcmap.net/q/1220950/-swift-package-manager-unable-to-compile-ncurses-installed-through-homebrew

Mongol

Excellent stuff on there... I'm fighting against my MacPorts (instead of Brew), but getting already somewhere!! ... Now I can compile and link using my macports ncurses.h, but still no support for A_BOLD in compilation time... WIP, let's hope I'm near – Vomitory

You can try to use attron(1 << (13 + 8)). A_BOLD is defined as macro using another macro, see ncurses.h. C macros that are more complex than simple constant definitions have no counterpart in Swift. see here developer.apple.com/documentation/swift/… for more information. – Megaspore

Ahá, we're narrowing down a completely different problem here... After having succesfully compiled my macports ncurses (with the solution proposed in @Mongol 's thread), and testing that A_BOLD is explicitly defined in the new ncurses (effectively, as raising bit 13), the problem seems to be completely different. By reasons unknown to me, some macros inside macports modern ncurses.h are completely INVISIBLE to my swift code, while some of them are perfectly usable... It even deserved a different question here in S.O... Whatever, as an ugly workaround, effectively, attron (1 << (13 + 8)) works ok. – Vomitory

(Continuation), effectively, MANY ncurses.h macros are (not that) complex bit calculations, but not simple for the swift C-Macro importer engine, so, even having been able to import a proper and modern ncurses.h, squeezing the maximum from it won't be possible under Swift. So sad (!!) and unexpected! I will have to make some swift wrapper to be able to use these macros as functions, but I feel it's an ugly workaround. Thanks, my original problem was probably that one, as A_BOLD is also defined inside the old MacOS SDK ncurses.h, but the Swift C-Macro import engine ignored them. THANKS a lot :) – Vomitory

I will finally answer in my other "Ncurses" question I posted some days ago here ( #56260559 ), with the original issue raising all this ncurses importing overkill solution. I will give the more than deserved proper credit to @StephanSchlecht who put me behind this lead regarding this somewhat dark "Swift + C macros import" unexpected behaviour. – Vomitory