Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds quite a bit of setup that luckily is mostly set-and-forget. It's the "technically more correct" approach compared to #7 (and Flathub prefers compiling from source versus downloading binaries), but I don't love it as it requires compiling all of Godot Engine just to export the PCK file when we'd want to update the Flatpak—it isn't the end of the world, but seems like overkill and just makes it take longer.
The gist is:
export/flatpak/net.hhoney.rota.json
is your game's Flatpak manifest; it's what tells Flatpak Builder how to actually package your app as a Flatpakexport/flatpak/modules/
contains build dependencies that are referenced in the manifest; things like Godot Engine itself and its dependenciesThe manifest's
build-commands
step walks through the actual process:--export-pack
to just export the PCK fileI think the alternative approach of #7 of automatically exporting the PCK file in CI when you make a release is perfectly reasonable, and is similar to what other (albeit possibly closed source) Godot Engine games do. It's less reproducible from source code and it requires exporting the PCK file out of band from the Flatpak build (and making releases on GitHub), but it feels a lot simpler.
Either way, the manifest contents in this repo are really more for testing and reference, as a manifest needs to be submitted to Flathub as a PR; I can get that started for you and make sure you get added as the maintainer, and we'll probably get some good feedback from people who know more about Flatpak than me!
I'll also ask around in the Flatpak and Flathub Matrix chat rooms to get a second opinion; I know there has been talk of improving the process of packaging Godot Engine games, and maybe this is the push it takes to get that to happen. 😁
Full disclosure that this PR as-is is probably not ready—I'm almost certain we should include some
cleanup
rules in the manifest to prevent shipping build dependencies in the final Flatpak.