Post

Replies

Boosts

Views

Activity

Reply to Path conflicts when using angle-bracket includes in umbrella header
Thanks for the response. To be clear, this is my own library so reworking how it builds (even abandoning frameworks) is no huge issue. Frameworks for iOS and MacOS are simply convenient packaging for the resources (and Metal shaders) that go with it. My main concerns here are to 1) make sure there isn't something wrong in my build settings, and 2) understand what's actually happening with the include paths. I actually tried a custom framework header, but the warning is triggered not only from the umbrella header, but from any of the headers included by umbrella header. It seems that all public includes are expected to only reference the system search paths. Regarding /usr/local, since that's kinda the typical place to install stuff on any Unix platform, so when installing as a static/shared library--even on Apple platforms--that's where it goes by default. The fact that an older version is installed somewhere on the system shouldn't break the build. Anyway, I've disabled the warning for the time being. If frameworks are no longer viable for cross-platform code it's seriously annoying and unfortunate, but not catastrophic.
Jan ’21
Reply to Path conflicts when using angle-bracket includes in umbrella header
Say the structure for project 'mylib' is: project/include/mylib.h project/include/header1.h project/include/header2.h project/src/file.c With the resulting framework structure something like: mylib/Versions/A/mylib mylib/Versions/A/Headers/mylib.h mylib/Versions/A/Headers/header1.h mylib/Versions/A/Headers/header2.h The new requirements wants only angle brackets in all framework headers, but that doesn't work for internal dependencies. Say 'header2.h' were to try including 'header1.h" with something like: #include <mylib/header.h> That include path will be incorrect when building the project--there is no real 'mylib' directory. Maybe Xcode hacks the include paths to magically work, but other toolchains have no way of doing that. Also, if there's an installed version of the headers in '/usr/local/include/mylib', a normal C toolchain will try to include 'header1.h' from there instead of from the project directory. It seems to me that Apple (or the clang devs) have redefined what angle bracket includes mean within the context of a framework, and the new definition is not compatible with non-Xcode toolchains. I currently have the warning disabled, but if at all possible I'd like to be creating properly structured frameworks.
Jan ’21