[swift-users] SPM & Library with bridging header

[Rien]

I may be missing something here, so please bear with me...

The client of the lib only has to see the headers that describe the lib, not the headers of the files that were used to create the lib.
Or are you referring to a case were the lib also exposes the headers of the libs that were used to create the lib?

Additional info:
In my particular case I use openSSL and have created a few Swift operations that use (wrap) openSSL. My lib does not expose openSSL to the client of the lib.
I did have to create a 2 line c-function for a callback. That function is not exposed to the lib client. But this two line function is the reason for the “mixed language” target.
Ideally no client should use openSSL directly, but it cannot be prevent of course that a client links its own files to openSSL using his own bridging file.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 20 Jan 2017, at 18:39, Jordan Rose <jordan_rose at apple.com> 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.
> 
> Sorry for the trouble,
> Jordan
> 
> 
>> On Jan 20, 2017, at 08:49, Rien via swift-users <swift-users at 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
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>