> On Jan 20, 2017, at 9:39 AM, Jordan Rose via swift-users > <swift-users@swift.org> wrote: > > Hi, Rien. Libraries don’t support bridging headers because the client of the > library has to be able to import the header, and arbitrary bridging headers > may conflict. (This is actually the primary purpose of modules for > Objective-C: to declare a group of headers that are self-contained—besides > what other modules they import—and can therefore be imported earlier or later > without difficulty.) The compiler will mildly try to stop you from doing this > if it can figure out you’re building a library, but it’s a bad idea no matter > what. Even if everything appears to compile fine, it’s likely you’ll get > inscrutable errors when trying te debug anything that uses your library. > > The particular difference between Xcode-created frameworks and > SwiftPM-generated libraries is that Xcode frameworks are set up to be > mixed-source, using the Objective-C public umbrella header in place of a > bridging header. SwiftPM doesn’t support mixed-source targets. (Since I don’t > work on SwiftPM myself I don’t know if there are any public plans to do so.) > > The recommended solution is to group your Objective-C headers into modules > (usually just frameworks) and import them that way, rather than to jam them > in via a bridging header.
That is correct, we have no immediate plans to support a mixed source model, our recommendation is to expose any C/C++/Objective-C through a clean modular interface, and then import that and use it in your higher level Swift modules. - Daniel > > Sorry for the trouble, > Jordan > > >> On Jan 20, 2017, at 08:49, Rien via swift-users <swift-users@swift.org >> <mailto:swift-users@swift.org>> wrote: >> >> I noticed something strange about Xcode and SPM concerning the capability to >> generate Libraries. >> >> When I try to create a Library in Xcode and then want to add an Objective-C >> bridging header, that is denied. It claims that bridging is not supported >> for Libraries. >> >> When I create an Xcode project through the SPM (with “swift package >> generate-xcodeproj”) then I can use bridging headers, even though the end >> result is a library. >> >> Question: Is this a viable work around? or are there hidden dangers that >> might not be immediately apparent? >> >> As a side note: SPM complains about multiple languages and currently only >> supports pure Swift modules. >> This creates the strange situation that I now use SPM to create an xcode >> project and then use Xcode to create bridged mixed language libraries. >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl <http://balancingrock.nl/> >> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/> >> Github: http://github.com/Swiftrien <http://github.com/Swiftrien> >> Project: http://swiftfire.nl <http://swiftfire.nl/> >> >> >> >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
