Add support for Snap package format

[shsorbom]

Changes:

• Add support for Ubuntu's Snap package format, which will allow a single binary to be run across multiple Lnux distributions
• Update Readme.md with build and installation instructions for Snaps

Notes:

• Currently, data files must be installed on a per-user basis, See Readme.md for details
• In theory, it is possible to build directly from github. This would greatly simplify package maintenance in the future
• adding the Falltergeist Snap to the Ubuntu store should be done by maintainers at some point in the future. This would allow users to test Falltergeist without bypassing snapd's security restrictions
• Future commits will test to make sure strict application confinement works.

[janisozaur]

a1sa? Isn't that some typo?

[shsorbom]

Yes... 🤦‍♂️ That explains the warning at install. I'm not 100% sure its needed but I will fix it.

[janisozaur]

Does snap automatically figure out the cmake's build type?

[shsorbom]

build type is determined by this line
plugin: cmake

Wait, do you mean build architecture? If so, yes.

[alexeevdv]

Can you please explain what is causing these limitations with data files location? we are going to have rewriten Resource Manager soon. It will support any amount of different locations mounted into the one virtual location. It is based on https://github.com/fgenesis/ttvfs. Can we do something with those restrictions?

[shsorbom]

The snap is bundled as a static filesystem image. It's contents are read-only. Snap apps in traditional confinement aren't aware of the rest of the filesystem (except for the ~/snap/[application]/[revision]/ directory and the locations defined in $SNAP_DATA and $SNAP_COMMON). Therefore when a Snap compiled version of falltergeist is looking in /usr/share/falltergeist, it is actually looking in the read-only version of the /usr/ directory that ships with the snap. The user cannot put data there, because, well, its read only. The designers of snap got around this issue by saying that non-static data was to be written to the $SNAP_DATA or $SNAP_COMMON or ~/snap/[application]/ directories. In theory, remounting the $SNAP_COMMON/usr/share/falltergeist/ directory (which IS read-write) as /usr/share/falltergeist should do the trick, but I haven't figured out how to do that yet. I'm currently seeking help on the correct way to do this task. Snap is supposed to be non-invasive, so you shouldn't need to re-write code to accommodate it. The problem is purely a lack of knowledge on my part :(

[shsorbom]

More info on snap confinement:
https://docs.snapcraft.io/reference/confinement

On SNAP_COMMON vs SNAP_DATA:
https://docs.snapcraft.io/reference/env

[shsorbom]

So, for now snaps don't have the capability I described. but they soon will. For now the only way to have globally accessible data would be to have an override flag available in falltergeist that allows the user to manually set the data path to $SNAP_COMMON (or have an environment variable):
https://forum.snapcraft.io/t/how-to-expose-snap-common-usr-share-game-as-usr-share-game/3803

[shsorbom]

Something occurred to me, would it be possible to have a GAME_DATA_PATH variable in the main cmake file for now? If so, snap has facilities to override cmake variables. The default should remain $PREFIX/falltergeist, but it would be handy to be able to set it.

[shsorbom]

Hi, I just thought you guys should know that there have been a few changes to the snapcraft.yaml syntax since I first opened this pull request. I fixed the only blocker issue that I know about, so it should build again. There is a deprecation warning I still need to look into, but building should be safe for the moment.