Looking for current guidance on packaging native libraries

Hello,

I wrote a binding to Google's Skia library for Swift [1]. Skia is a nice 2D graphics API that can be hardware accelerated and powers both Chrome and the Android graphics stack and happens to run on almost every platform.

I developed this on a Mac with Xcode so I ended up with frameworks for iOS, macOS and tvOS [2], and I believe there are enough blog posts to figure out how to make a system .framework that can be consumed by apps on the Apple ecosystem.

My real goal though, was to make this available on Linux and Windows and this is where I am looking for some help. My Skia bindings rely on the work that we did at Xamarin to surface the Skia API to C [3].

Building Skia is not exactly the most fun activity, and I would like to make the life of my users easier by reusing the native libraries that we are already building with Azure Pipelines [4] without having to build this either myself, or forcing users to do this on their target systems.

What can I do today to achieve this?

[1] https://github.com/migueldeicaza/SkiaKit
[2] I should do watchOS at some point, just not bothered to do it yet.
[3] https://github.com/mono/skia - the reason for using this fork is that it surfaces a C API that is easy to invoke from Swift and has a stable ABI. While Google did start work on a C binding for Skia, it is very limited, so we built upon that foundation and created a complete ABI-stable binding.
[4] https://dev.azure.com/xamarin/public/_build?definitionId=4&_a=summary

5 Likes

Hi @migueldeicaza,

Sorry, I'm not going to be much help on the packaging aspect for Linux and Windows. That is a complex problem and dependent on how you intend to distribute the binaries. Linux is particularly complicated because the distribution and the version of the distribution are extremely critical as the libraries can be incompatible. Windows is slightly easier, with only the minimum SDK version to consider. However, distribution of the binary artifacts from something like s-p-m is something that I am unfamiliar with although @Aciid may have thoughts on that. If you are simply trying to distribute the Windows binaries as a zip file, that seems somewhat easier.

However, there is something else which prompted this reply - it sounds like you want to distribute Swift code on Windows, building on Azure pipelines. I feel as though you may be able to actually help me with this problem. I have builds of the Swift toolchain for Windows and the Swift SDK for Windows x64, two of the three pieces needed to build Swift code for Windows. The third missing piece is the Windows SDK (available as part of VS - it is already part of the hosted pipelines images). Although the necessary pieces are available, they are not entirely the easiest thing to use, due to both complications of Swift as well as Azure (or more specifically, my lack of knowledge around it).

For the Swift aspect, I have spoken previously with Jordan and @brentdax and I hope that Apple will push through the changes that they are worried about collisions on and enable the simplification of using Swift. For the time being, what this amounts to is more complexity in the invocation of Swift and the need to setup some environment variables and Swift compile flags. This is inconvenient but tractable and there is some reference work that I have for WIndows available.

The part of the problem that I believe that you would be able to help simplify and ease is the integration with Azure. How could we actually get builds of the toolchain and the Swift SDK made available for easier consumption in other pipelines? I was unable to really figure out how to use the release pipelines for building something that others could easily consume, though, there are artifacts for the builds which can be used for further builds.

I hope that some of the existing work is helpful. I'm happy to try to point you in the direction of the existing work that you may be able to leverage or to try to answer questions about that.

Saleem

2 Likes

Hello,

It depends on what you want to do with your artifacts at the end. I suspect that is the key, and I have to admit that I do not really use Windows, so it is hard for me to give some guidance in this space.

My guess is that you likely want to produce an MSI package and then distribute the resulting MSI, like this:

Well, in this particular case - the intent is to make it easy for people using Azure Pipelines to be able to build Swift code for Windows and Linux. There is some existing work that I have done to generate MSIs actually, though the recent merge has caused some regressions (need to fix up the SDK MSI generation, but the toolchain MSI is working again).

@migueldeicaza, check out this one https://github.com/rust-skia/skia-binaries, rust-skia is using prebuilt binaries. they are downloding and installing binaries over platform configrations. https://github.com/rust-skia/rust-skia/blob/master/skia-bindings/build.rs

@compnerd and @migueldeicaza, you can also use GitHub-hosted runners for Windows in github actions.

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners

1 Like

@satishb, are these prebuilt or do they require users to build them?

The goal of my questioning was to try to figure out what needs to be done to ease building software written in Swift for Linux and Windows, particularly as it pertains to Azure Pipelines (though, Im interested in that problem in general as well).

Right, I imagine Rust has a mechanism to do this.

My question is how to do this for Swift

Yes, check release assets. https://github.com/rust-skia/skia-binaries/releases

Right - I know how to get the binary assets, I have them here, and can get them on demand.

What I am looking for is guidance to allow third parties to easily include SkiaKit in their Swift projects in non-Apple platforms.

Terms of Service

Privacy Policy

Cookie Policy