SPM & Library with bridging header


(Rien) #1

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


(Jordan Rose) #2

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


(Daniel Dunbar) #3

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

···

On Jan 20, 2017, at 9:39 AM, Jordan Rose via swift-users <swift-users@swift.org> wrote:

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


(Rien) #4

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


(Rien) #5

The thing I was missing is the “system module”.. found it now though :wink:

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


(Daniel Dunbar) #6

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 <swift-users@swift.org> wrote:

The thing I was missing is the “system module”.. found it now though :wink:

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


(Rien) #7
···

==================================================
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](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 daniel_dunbar@apple.com 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 swift-users@swift.org wrote:

The thing I was missing is the “system module”… found it now though :wink:

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