The thing I was missing is the “system module”.. found it now though ;-)
So far so good, I want to put that little glue code I need in its own module. However I cannot find how to specify the import search path. “swift build -I /usr/local/include/“ does not work (unknown command -I) And pkgConfig cannot be used on a non-system module. But without specifying the import search path, SPM cannot compile the c-code. Any suggestions? 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 19:48, Rien via swift-users <swift-users@swift.org> wrote: > > 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_r...@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@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@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
