Over the course of Swift's existence I've had to take advantage of a number of workarounds (i.e., hacks) to compile a Swift framework that utilizes non-modular system code, e.g., CommonCrypto, sqlite3, etc.
These "solutions" have included:
- Renaming the umbrella header to be something different than the module name in order to exploit a bug that let frameworks compile with bridging headers, wherein the non-modular import happened:
#import <CommonCrypto/CommonCrypto.h>
- Building a dummy, optional framework with a custom module map specifying the absolute path to an SDK header (relative SDK paths don't work):
module CommonCrypto [system] [extern_c] { header "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/CommonCrypto/CommonCrypto.h" export * }
- Specifying a custom module map with an additional header specifying the absolute path to an SDK header:
framework module MyCrypto { umbrella header "MyCrypto.h" header "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/CommonCrypto/CommonCrypto.h" export * module * { export * } }
- Using "@asmname" and linking to the dylib.
- Copying a version of the header and linking to the dylib.
None of these workarounds seem to work anymore. The bridging header hack appears to have been patched, and any attempt to use a module map, @asmname, or otherwise fails because an attempt to "link binary with [static] libraries" adds a ".tbd" file instead of a dylib, and not all of the symbols appear to make it over for the given architecture.
And so, I implore all that listen: is there any way to write a framework-level Swift wrapper over this kind of system-level code? And—if not—can we please have module maps with the next Xcode 7 beta? Please?