We currently are developing a LibSSH wrapper using Swift + Combine and for the development phase it was all on a project with all of the dependencies in the Frameworks folder, dependencies are:
- libsshd.a
- libssh.h
- libz.tbd
- openssl.framework
- include
For the dependencies to be accesible in the project we've got a shim and module map in the project as follows:
File shim.h
#ifndef shim_h
#define shim_h
// A shim header to bridge C to a Swift modulemap
#include <libssh/libssh.h>
#include <libssh/callbacks.h>
#include <libssh/sftp.h>
#endif /* shim_h */
File module.modulemap
/// Expose LIbSSH for extraneous Swift usage
module LibSSH {
header "shim.h"
}
Our plan is to migrate this wrapper to a Swift Package which can be later used on our app as a SPM dependency. This year's WWDC Session 10147 explains the possibility of adding binary frameworks to Swift packages.
Creating a Swift PM yields to some errors which we're not able to solve. To be able to do this we've created a XCFramework from the previous openssl.framework stripping all architectures and only leaving x86_64. The current package structure is as follows:
.
├── OpenSSL.xcframework
├── Package.swift
├── README.md
├── Sources
│ └── BKSSH
│ └── Our Swift code for the wrapper
└── include
├── module.modulemap
└── shim.h
File Package.swift
// swift-tools-version:5.3
import PackageDescription
let package = Package(
name: "BKSSH",
products: [
.library(name: "BKSSH",targets: ["BKSSH"]),
],
targets: [
.target(name: "BKSSH", dependencies: [.byName(name: "OpenSSL")]),
.binaryTarget(name: "OpenSSL", path: "OpenSSL.xcframework"),
])
Building this from the console produces the following error:
error: artifact 'OpenSSL' does not support the target platform and architecture ('Triple(tripleString: "x86_64-apple-macosx", arch: SPMBuildCore.Triple.Arch.x86_64, vendor: SPMBuildCore.Triple.Vendor.apple, os: SPMBuildCore.Triple.OS.macOS, abi: SPMBuildCore.Triple.ABI.unknown)')
/.../BKSSH/Sources/BKSSH/BKSSH.swift:5:8: error: no such module 'OpenSSL'
import OpenSSL
All of this leaves us with the question if is possible to create a module map for a binaryPath. Maybe there's another way to approach this we've not yet considered and are missing