What is the glue code you need? You can define a C/Obj-C target in the same Swift package, and then use it from your Swift targets. See: https://github.com/apple/swift-package-manager/blob/master/Documentation/Reference.md#source-layouts <https://github.com/apple/swift-package-manager/blob/master/Documentation/Reference.md#source-layouts> for more information.
- Daniel > On Jan 21, 2017, at 2:24 AM, Rien via swift-users <swift-users@swift.org> > wrote: > > 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
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
