==================================================
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 <daniel_dun...@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 ;-)
>>
>> 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
