Re: [swift-users] SPM & Library with bridging header

[Rien via swift-users]

==
This works:
==

First I need openSSL from Swift, that I have done with COpenSsl:

Package.swift:

import PackageDescription

let package = Package(
name: "COpenSsl",
pkgConfig: "openssl"
)


module.modulemap:

module COpenSsl [system] {
  header "/usr/local/include/openssl/ssl.h"
  header "/usr/local/include/openssl/err.h"
  header "/usr/local/include/openssl/crypto.h"
  header "/usr/local/include/openssl/evp.h"
  header "/usr/local/include/openssl/x509v3.h"
  export *
}

And then import this into Swift with:

import COpenSsl


==
This does not work
==

Package.swift for the C-glue code:

import PackageDescription

let package = Package(
name: "OpenSsl",
dependencies: [
.Package(url: "https://github.com/Swiftrien/COpenSsl;, "0.1.0")
]
)



OpenSsl.h:
(In Sources/include)

// #import "openssl/ssl.h"
// #import "openssl/x509.h"
// #import "openssl/x509v3.h"

@import COpenSsl;

void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, int *, 
void *), void *arg);

void skGeneralNamePopFree(STACK_OF(GENERAL_NAME) *san_names);



OpenSsl.c:
(In Sources)

#include "OpenSsl.h"

void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, int *, 
void *), void *arg) {
SSL_CTX_set_tlsext_servername_arg(ctx, arg);
SSL_CTX_set_tlsext_servername_callback(ctx, cb);
}

void skGeneralNamePopFree(STACK_OF(GENERAL_NAME) *san_names) {
sk_GENERAL_NAME_pop_free(san_names, GENERAL_NAME_free);
}


The @import COpenSsl; statement does not work. Nor do the normal includes.
Hence the compilation fails.

Maybe the import statement is wrong? is there another way to do this?

Regards,
Rien

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




> On 22 Jan 2017, at 06:25, Daniel Dunbar  wrote:
> 
> 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
> for more information.
> 
>  - Daniel
> 
>> On Jan 21, 2017, at 2:24 AM, Rien via swift-users  
>> 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  
>>> 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  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 

Re: [swift-users] SPM & Library with bridging header

[Rien via swift-users]

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  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  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  
>>> 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

Re: [swift-users] SPM & Library with bridging header

[Jordan Rose via swift-users]

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  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