Open b-ncMN opened 2 years ago
libcompression
so an alternative zip library would have to be used. This library was the most performant one I could find, so maybe only use a separate one on Linux and keep this one on Apple platforms (unzipping is one of the longest steps on first launch).CommonCrypto
libraryPerfect-Crypto
package.JSONDecoder
on Linux until support is added, because this package's only purpose is to be a faster JSONDecoder
.Overall, it shouldn't be too much work to get all of the dependencies building on Linux.
I don't think there is too much platform specific code in Delta Core that isn't related to the UI or rendering. It should be relatively easy to use compiler directives to skip them on non-Apple platforms.
Rendering is currently implemented using Apple's Metal framework. A renderer would have to be written for Linux using Vulcan or WebGPU or something. WebGPU would be preferable, but swift-webgpu would need to be made a bit easier to use. It would be good to abstract over the low level rendering stuff a bit so that mesh generation code can be the same for both renderers.
The client's UI is currently made with SwiftUI which is closed-source and only supports Apple platforms. When making this Linux port we'll probably need to make a second UI that uses Gtk or some other cross-platform solution. My SwiftCrossUI package could be cool but it's pretty experimental at the moment and not ready for making any remotely complex UIs.
Swift currently has issues producing statically linked executables. The best way to distribute Delta Client will probably be as a .deb
for now (the most common dists that I know of use that). An alternative could be distributing it as a folder containing the libraries and stuff and then having a wrapper script to launch it with the correct PATH
and library search path set.
Distribution isn't the top priority during development, so this can be left until a little further down the line.
@InfRandomness made some progress on the distribution aspect.
Static binaries can be built using swift build -Xswiftc -static-stdlib -Xswiftc -static-executable
. They also had to install libstdc++-static
for this command to run successfully.
Binaries are huge, but do at least work.
ZippyJSON Linux support : https://github.com/michaeleisel/ZippyJSON/issues/6
IDZSwiftCommonCrypto has been replaced with OpenSSL (pending whether it builds on Linux, but it should). ZippyJSON is being disabled on Linux until it adds Linux support. SIMD was replaced with FirebladeMath (but will need some PRs in future to add all required operators).
Network.framework will likely be replaced by Socket.swift
, because swift-nio
looks overcomplicated for Delta Client's simple use case.
All distros support AppImage, so if Swift supports that, then it would be a great option as well as the .deb for users on non-Debian based systems.
Swift supports neither, that’s what Swift Bundler will be for, but I am definitely leaning towards only supporting AppImage. Cause its closer to how Mac apps work and it supports all distros. And a simple wrapper deb around an AppImage should be simple to create to support apt and stuff.
I personally hate appimages because they don't "install" properly to app launchers without something like AppImageLauncher. So a deb would be nice too.
flatpak
I disagree with all of those point and strongly argue we should ship a statically linked musl binary alongside some packages upstream, for those who are wishing to create and maintain them.
I disagree with all of those point and strongly argue we should ship a statically linked musl binary
alongside some packages upstream, for those who are wishing to create and maintain them.
How does that work with the required resources and dynamic linking (for the plugin system)? The app kinda needs to be a few separate files, and I think AppImage can do that and combine them nicely into one? .deb would be the second easiest probably but that's annoyingly distro specific.
Also worth noting that the only thing preventing SwordRPC being built on Linux was a typo (PKBeam/SwordRPC#1)
OpenSSL has now replaced IDZSwiftCommonCrypto which brings Delta Core one step closer to building. I think the next step will be to separate rendering into a separate target so that Delta Core can build on Linux and be used to create bots etc until a Linux renderer is created.
FirebladeMath has now replaced SIMD and everything seems to be working correctly on macOS still. I have multiple PRs in the works to improve the library but for now I'm just using a branch on my fork.
I've replaced all of the networking with a custom Socket implementation now so we don't need to rely on Network.framework anymore (which is Apple platforms only). As an added bonus, we don't rely on NioDNS
(and therefore NIO
) anymore because before I was relying on Network.framework for most of the DNS resolution and NioDNS
wasn't capable enough to do it all. So I switched to a much more standalone DNS library that is way nicer to use too (because no NIO).
Now I've run into Compression
(another Apple platform only library) so I'll look into finding an alternative library for performing zlib compression/decompression.
I've replaced Compression
with a zlib library now and it seems to be working well
I think all that remains now to get a working build is to split rendering code into a separate target so that DeltaCore can be fully built on Linux.
I've split out rendering code and removed reliance on CoreGraphics now (by replacing image loading/processing with SwiftImage) and now I'm working on replacing CryptoKit (used for SHA1, RSA and shared secret generation.
Thanks! I hope adding all these libraries for cross platform doesn't make build and runtimes too much slower.
So far I think it has improved build times maybe cause we don't need to build stupid swift nio. But I'll definitely be benchmarking runtime performance before I merge, hopefully it won't be affected too much. I'll probably have to do some optimisation.
Just thought I should update this thread - #184 and #185 implement server list UI and configuration persistence on Linux respectively.
👀
The linux
branch is a year old, is this the branch I should be working out of -- or begin a new fresh branch based off inventory
?
It was deemed the linux
branch had already been merged into main
a long time ago -- I have created a new branch based off inventory
, and will attempt to usher in Linux support now.
As a follow-up from #112 I am opening this issue to track the work to be achieved to have the client work on Linux