Build for Linux and Windows in GitHub CI #422
Conversation
|
Cool, but who is this for? Who maintains this when it breaks? Who benefits enough to make it worth maintaining? I have to admit that as Neverball maintainer I am only interested in the Windows build. That's actually interesting. Fedora/Ubuntu packages don't make sense to me - I would never want to, in any scenario, to distribute and support those packages and compete with upstream solutions. (Also, Neverball has an active Flatpak maintainer so Linux feels covered.) Install documentation changes don't belong in this PR. We also don't need an Emscripten CI/CD because we already have one in another repo. All in all, if this is reduced to just Windows CI/CD, I would merge that without asking questions. |
|
The Linux builds for Fedora and Ubuntu aren't for distribution, in fact it's even not that practical as tarballs since .so files for dependencies aren't provided (you can't even use the Ubuntu build as is on Fedora since the actual The goal of the CI (for me) it to just make sure the build on these systems works, and provide a per commit temporary (artifacts get deleted after some times) testing builds it someone wants to test a recently made commit (or a PR) without going through the compilation stuff. Maintenance wise the cost is very low. The "highest" cost is probably just updating runner images and used actions, but those are typically supported for over 4 years and migrations paths are straightforward (speaking from experience). Occasional version bumps for target systems (not tied to the runners themselves, thanks to the containers), as well as updating the dependencies install command lines when adding new dependencies. Anyways I am usually invested into keeping things I contribute updated, so I will probably be able to do the maintenance of the CI when needed. I modified the install documentation because I had to figure out the dependency install command lines for the build workflows and thought it would be a nice addition to the documentation, if you want I can cherry-pick the commit in another PR. About the Steam Runtime 4.0 stuff, it was primarily made as an experiment (it's Debian 13 + a default set of libraries) with the Steam Runtime. I have a working patch for the SDL2_ttf problem, but it still lacks a bit of testing on my end. I can remove it all together, or add my patch if needed. Would you be against a Steam release of the game (in addition to #348) at some point in the future? About Emscripten build, where is the CI located? I searched for a bit and couldn't find it. macOS CI could be used to make CI builds of the app, including production builds (Luanti does this I think) |
2 participants
Add a GitHub Actions workflow to build for Linux and Windows, publish tarballs as workflow artifacts.
x64arm64x64arm64x64(UCRT)arm64(UCRT)x64arm64For Windows, I have picked the
CLANG64andCLANGARM64msys2 environments (Windows 10+) instead ofMINGW64, to use the newerUCRTC runtime instead of the olderMSVCRTruntime (unavailable to build for ARM).I have also added a disabled build workflow for the new Steam Linux Runtime 4.0, both for
x64andarm64.It uses
sdl2-compatto effectively run SDL2 apps on SDL3 and it doesn't pickSDL2_ttfright now. I have a working fix but I have not tested it extensively enough (weird failure in some cases).I successfully tested the Ubuntu build in Distrobox, the Fedora build natively, and the Windows build with Wine. ARM builds are untested outside of the CI step that run them with
--version.I improved the build documentation by switching it to Markdown and adding command lines to install dependencies on Ubuntu and Fedora. Also fixed some broken links (there are still a few with no clear replacements).
Leverages official GitHub Actions runners:
You can check the build logs and results here: AFCMS#1
What is still missing from the pipeline:
I consider this PR ready for review.