Version of OpenTTD: 1.9.3
Compared to snap/flatpak it doesn't enforce any 3rd-party tooling on destination machine, and can be considered like Mac DMGs or Windows ("portable") EXEs.
Under the hood it's just a SquashFS loopback filesystem with specified contents wrapped into ELF binary with actual code on top which mounts the FS as unprivileged user and spawn the application in it. It doesn't provide sandboxing (can be done with firejail on demand) in terms of security, just bundles everything what game/application needs in a single binary, thus being quite ideal for OSS games or "larger" self-contained applications like LibreOffice, Krita, and so on. Definitely not a thing for CLI apps, system tools and utiltiies (but no one prevents anyone from building these and they'll work just fine)
Steps to reproduce
At first I wanted to create a Pull Request for that, adding AppImage as a "bundle" (in
Instead, I'd like to share the steps which I manually did to achieve working AppImage add my thoughts on it and how OpenTTD behaves:
# "bionic" is codename for Ubuntu 18.04 LTS docker run -v "$OPENTTD_SOURCES_DIR:/openttd" -ti ubuntu:bionic bash --login
# "VERSION" is needed to indicate a version of software we build, in other cases it'll use a git/hg/cvs hash and store it in target filename and metadata (optional) VERSION=1.9.3 ./bin/linuxdeploy--appdir appdir/ --output appimage
docker run -v $HOME/src/openttd:/openttd -ti ubuntu:bionic bash --login cd /openttd apt install # ... dependencies ... # ./configure --prefix-dir=/usr --binary-dir=bin make -j8 make install INSTALL_DIR="appdir" wget # ... linuxdeploy URL # VERSION=1.9.3 ./linuxdeploy --appdir appdir --output appimage file OpenTTD-1.9.3-x86_64.AppImage
Issues I found
These are mostly cosmetic or formal ones, which can probably be addressed more officialy by someone not being dumb as me right now:
#!/usr/bin/env bash cd "$APPDIR/usr/share/games/openttd" # go to basedir "$APPDIR/usr/bin/openttd" $* # "$*" is to pass argument list from AppImage binary call
# you don't need to address .so.XX.y directly, linuxdeploy is a little smarter about symlinks and ABIs ./linuxdeploy \ --appdir appimage/ \ -output appimage \ --library /usr/lib/x86_64-linux-gnu/libiculx.so \ --library /usr/lib/x86_64-linux-gnu/libicutu.so \ --library /usr/lib/x86_64-linux-gnu/libicuuc.so \ --library /usr/lib/x86_64-linux-gnu/libicuio.so \ --library /usr/lib/x86_64-linux-gnu/libicui18n.so \ --library /usr/lib/x86_64-linux-gnu/libicudata.so \ --library /usr/lib/x86_64-linux-gnu/libicu-le-hb.so
Why I'm doing this here, instead of maintaining it on my own?
A little disclaimer
If you find this like forcing or advertising a new technology, it's not. I'm not affiliated in @probonopd or AppImage project in any way. The whole reasoning is that I wanted to quickly share an OpenTTD build for many different platforms and make it as most easy as possible, without polluting the host system. It worked pretty well and I've been looking forward to integrate such distribution form to other users.
P.S.: Dedicated server build can be done that way too, making them deployable in seconds.
The text was updated successfully, but these errors were encountered:
The CMake transition was committed a while ago, in commit 56d54cf (and has been fixed-up in various ways since).
Thank you for the offer of help! It might be best if you join the IRC channel -- #openttd on irc.oftc.net , most active in EU evenings/weekends -- to discuss it. Or stick with GitHub comments, that works too. :-)
I was a bit lazy to compile OpenTTD from sources, instead I used the latest binary you publish to build this AppImage. Nevertheless the recipe should work if you build it from sources and install it into an AppDir.
If you help me setup a workflow for the build, I could add the AppImage packaging bit
Here is the link to my project: https://github.com/azubieta/openttd-appimage
What we do have these days, is a
Both combined should address this issue, I believe :) So going to close it for now, but let me know if there is anything else to this issue! :)