Are there more comprehensive/detailed plans for shipping native libraries along with Silk.NET bindings?

[UltzLtd]

Issue by alexrp
Friday Dec 25, 2020 at 20:39 GMT
Originally opened as Ultz/NativePackages#3

---

Hi,

I've been looking at using Silk.NET for one of my projects. An important goal for that project is that it must be able to be shipped using dotnet publish -p:PublishSingleFile=true -r win-x64 (and win-x86, linux-x64, osx-x64) and not have too many external dependencies.

For some libraries that Silk.NET wraps, it's reasonable not to bother including them with the application since the platform will almost certainly have a reasonably up-to-date version of the library installed, as is the case for OpenGL, for example. However, for others (Assimp, GLFW, SDL, OpenAL, Vulkan, OpenXR), there's either not a system-wide library available anywhere or only on a subset of the supported platforms. For some of these (Assimp, GLFW, SDL), Silk.NET already has NuGet packages containing the native libraries, which is great. But it seems to me that the following are currently missing:

• OpenAL (oal_soft)
• Vulkan (mainly MoltenVK for macOS; Windows and Linux tend to have system-wide libraries available)
• OpenXR (this ecosystem seems to be a bit confusing from my outsider perspective)

So, I have three questions:

• Are there any plans to include the above libraries in NuGet packages to make publishing self-contained applications easier?
• Are there such plans for new bindings being considered for SIlk.NET (e.g. FEMFX)?
• Are there any plans to include libraries for other architectures? For example, linux-arm, linux-arm64, win-arm64 are all supported officially by .NET 5+.

[UltzLtd]

Comment by Perksey
Friday Dec 25, 2020 at 21:09 GMT

---

OpenAL (oal_soft)
Vulkan (mainly MoltenVK for macOS; Windows and Linux tend to have system-wide libraries available)
OpenXR (this ecosystem seems to be a bit confusing from my outsider perspective)

These are all really good points, and yeah one day we should provide similar packages for these platforms. For OpenAL, this was a massive oversight, as we did intend to make one back in the 1.0 Preview days but clearly never got around to it. For OpenXR, yeah the ecosystem is really confusing however Silk.NET makes use of the OpenXR Loader, which is a library that handles all these different loading mechanisms by just exposing the functions as exports. MoltenVK is an excellent shout too as that'd help with portability a lot. Silk.NET is actually configured to use a file called libMoltenVK.dylib if present and just work on macOS.

All of these are really good suggestions that we're interested in, but just don't have the time to implement immediately. Would welcome PRs.

Are there any plans to include the above libraries in NuGet packages to make publishing self-contained applications easier?

The Ultz.Native.* packages are referenced by Silk.NET and, if you do a non-single-file runtime-specific publish (such as dotnet publish -r win-x64 --self-contained true) you will see that SDL2.dll, glfw3.dll, and Assimp64.dll are copied into the directory. However, I haven't found a way to get this to work with single-file applications yet.

Are there such plans for new bindings being considered for SIlk.NET (e.g. FEMFX)?

Yes! Lots! If you'd like to find out more, feel free to open up a discussion in the Silk.NET repo or join the Discord server.

Are there any plans to include libraries for other architectures? For example, linux-arm, linux-arm64, win-arm64 are all supported officially by .NET 5+.

More than happy too, the main issue is someone needs to compile the actual libraries for those platforms. All of our Linux libraries were generously compiled by @devvoid, and the rest were either sourced from an official source (such as GLFW which ships its Windows libraries in a zip file on its website) or compiled locally.

Once again, more than happy to accept PRs for this!

[Perksey]

On the back of this, we should make a Silk.NET ANGLE distribution.

[Perksey]

I'm going to close this as it's a bit of an open-ended issue, and we've improved our native library packages since this issue has been created.