Packaging C libs as framework, good idea? If so I have questions

Question

Created Aug ’22

Replies 2

Boosts 0

Participants 2

We bit the bullet of massaging our CMake stuff to package our cross-platform SDK library & C headers as a framework for Mac & iOS.

Assuming this is indeed a sensible thing to do, our cross-platform examples and our end users' code now need "#if APPLE / #include <Thingie/header.h> / #else / #include <header.h>", and to setup framework search paths instead of header search paths for this SDK.

Question 1: Is it definite that <Thingie/header.h> is going to be necessary when using the framework, and there's no special cases where "#include <header.h>" also finds headers within frameworks for C/C++ code?

Question 2: For macOS projects specifically, how janky is it to add "Thingie.framework/Headers" to the C/C++ header search paths (instead of setting the framework search path) so that such ifdefs around the includes aren't needed. Is this even a remotely-common practice or is it super ugly, and/or hazardous for any reason?

Question 3: Do Mac SDKs always do one or the other, embrace framework or have lib and loose headers fully cross-platform-wise? Does anyone else ever include the latter like the windows/linux variants of their SDKs, but also package a framework and let macOS users choose either option?

Thanks!

Boost

Answer 1

mansourmoufid OP

Aug ’22

iOS supports only frameworks, and macOS supports both frameworks and dynamic libraries.

Generally, people who specifically need frameworks are using Xcode, so you can provide them with an Xcode project, and they do the <Thingie/header.h> thing in their own code. CMake lets you output Xcode projects.

0

Answer 2

JohnHoustonQG OP

Aug ’22

Yes, we're clearly not the general case. We're shipping a cross-platform (ie. Windows/Linux/Mac) SDK and have been updating it to bundle Mac libraries/headers as frameworks. Some of our example code that uses these frameworks has been plain C/C++ CLI executables, common source for all platforms (with a small amount of special cases for each platform in the code and build files, fewer of these is better). We use CMake to build the SDK, and also to build the examples (so double dose of madness to anyone accustomed to just Xcode). Eventually we may have additional examples that use the frameworks correctly as frameworks, but we still want the existing ones to work mostly as-is.

I spoke of just headers in my Question 2, but similarly need library search paths that "dive into" bundles to link to the dylibs of course. Others on my team are running with this janky approach and it looks like it's working for us at the moment, and seemingly keeping the Mac special cases in the code and CMake to a minimum. I'm hoping to provide more context to the final go/no-go on this plan.

Is this a super oddball scenario for a SDK and are we on our own to figure this out? Or are there at all any others in this same boat? The cross-platform code boat that's using frameworks not quite as intended, that is. How seaworthy is this boat?!

0