Delta Client Linux support tracking issue

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

[stackotter]

Overview

• Make all dependencies successfully build on Linux or find alternatives
• Make Delta Core build on Linux (with rendering disabled)
  • By this I mean get it to a point where someone could write a bot client with it
• Write a renderer for Linux
• Write a UI for Linux
• Find a way to distribute the client for Linux

Dependencies

• zipfoundation
  • Relies on Apple's 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).
• idzswiftcommoncrypto
  • This relies on Apple's CommonCrypto library
  • We might be able to move to this CommonCrypto port that adds Linux support
  • Or maybe the Perfect-Crypto package.
• delta-logger
• niodns
• swift-protobuf
• swift-collections
• swift-concurrency
  • It seems like this package is only written with Apple platforms in mind. But it might build on Linux, just need to build it and see.
  • If it doesn't support Linux, it would probably be easy enough to find a different atomics solution (if I remember correctly, I only used this package in one file).
• ecs
• zippyjson
  • It seems like this package was only created for Apple platforms. But it might not be that far off being able to build on Linux. Either way, this package isn't essential and could just be replaced with the regular JSONDecoder on Linux until support is added, because this package's only purpose is to be a faster JSONDecoder.
• swift-parsing
• swift-argument-parser
• swordrpc
  • This might be able to be built on Linux (assuming that Discord rich presence works the same way on Linux) because its only bluesocket which supports Linux.

Overall, it shouldn't be too much work to get all of the dependencies building on Linux.

Delta Core

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

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.

UI

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.

Distribution

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.

[stackotter]

@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 : michaeleisel/ZippyJSON#6

[stackotter]

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.

[nekename]

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.

[stackotter]

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.

[nekename]

I personally hate appimages because they don't "install" properly to app launchers without something like AppImageLauncher.
So a deb would be nice too.

[Bixilon]

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.

[stackotter]

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.

[nekename]

#134 introduces CustomJSONDecoder as a wrapper for JSON decoding, using ZippyJSON on Apple platforms and Foundation on Linux. Additionally, with help from @LeoDog896, the PR successfully replaces swift-concurrency with swift-atomics.