Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create AppImage for Linux x86_64 and aarch64 #30

Merged
merged 9 commits into from
Sep 5, 2024

Conversation

orazioedoardo
Copy link
Contributor

@orazioedoardo orazioedoardo commented Sep 4, 2024

Linux has a solution to distribute portable apps like on macOS, it's called AppImage. It works similarly to what you are currently doing with makeapp_linux but packages everything inside a single executable which mounts an ephemeral read-only filesystem. This way the user only needs to download the file, make it executable and double click.

You can download a test build for x86_64 here and for aarch64 here. The aarch64 version is built on QEMU within a docker container that shares a folder with the host. appimagetoolkit gives an error when running in the virtual machine so it has to be build on the host. See here for more information on the action. Tested on aarch64 virtual machines (Debian, Ubuntu, Fedora). Might be interesting to try on a Raspberry Pi.

Bootstrap script was sourced from this repo.

Since the file system is read-only, preferences, high scores and save files can't be saved to the current directory, so this pull request makes changes to use XDG_CONFIG_HOME and XDG_DATA_HOME when available, falling back to the conventions. There are also some other minor changes explained in the commit log.

Note I haven't checked whether these changes impact Windows but shouldn't.

For simplicity, I recommend shipping the .AppImage file directly instead of zipping it, as the .AppImage is already compressed / high entropy so you wouldn't benefit from the compression and it's an extra step for users. Similarly but a bit off-topic, ship the .dmg file for Mac instead of the zip with the dmg file inside.

@silverweed
Copy link
Owner

silverweed commented Sep 4, 2024

Oh, wow, this looks like a great improvement, thanks for the initiative! Maybe this way the game can finally get working Linux builds! :D

I like the idea of making things uniform again among all OSes, and having levels.json inside assets/ surely makes sense.
Moving the default locations of the preferences, high scores and saves is good on one hand, as it means upgrading the game won't require manually moving the files over to a new directory, and less good on the other, as it makes it convenient to just copy-paste the entire directory to a new drive for example. But I suppose the advantages outweigh the disadvantages.
If we go in that direction we might wanna do the same on Windows and put those files in %appdata% or something.
The level editor would also require some changing to find those files, but that's not a big deal.
Overall, having a solid Linux build, and the added bonus of having it integrated in the CI, outweighs these minor issues I believe.

As for building for ARM, I don't know how common that is but I imagine not very much, so unless there is specific request for it I think we can do without, at least for now.

Thanks again for the big contribution! I'll integrate it as soon as I have a bit of time - hopefully this evening - so I can also update the download page and make a quick post about it.

@orazioedoardo orazioedoardo changed the title Create AppImage for Linux x86_64 Create AppImage for Linux x86_64 and aarch64 Sep 5, 2024
@silverweed silverweed merged commit 988929d into silverweed:boom Sep 5, 2024
@orazioedoardo
Copy link
Contributor Author

I've just noticed that ~/.local/share and ~/.config (or what's in the XDG environment variable) may not necessarily exist. Probably the lif:: createDirIfNotExisting method should recursively create the tree.

@silverweed
Copy link
Owner

@orazioedoardo thanks for pointing that out. I pushed 75af9b5 that uses std::filesystem::create_directories to fix the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants