Hi everyone, First of all excuse me if I'm not using the proper channel for this, but due to the lengthy nature of this email, I thought it more appropriate on this mailing list than as a comment in a new bug report asking for Godot to be packaged. TL;DR: If there's interest I can work with you to get Godot packaged in your distro, as I'm a Mageia (RPM) packager myself and Godot dev. --- I maintain a good deal of games and related libraries for Mageia [2], and am also an upstream contributor to Godot Engine [3]. I just packaged Godot's new release, 2.0-stable, the spec file (RPM) of which can be seen here [4]. Godot is a MIT licensed 2D and 3D game engine, which comes with a feature packed editor and scripting language to make games easily and export them to a wide variety of platforms (most desktop platforms, android and iOS, HTML5 via asm.js). I wanted to share some insider tips about how to package Godot most efficiently. The game engine comes with various components, which would ideally all be built and packaged, though only some (marked with (*)) are really necessary. There are no "make install" instructions, so the installation paths used are my own choice (and to some extent recommendation): - /usr/bin/godot(*): The editor tools for the X11 platform, built with `scons p=x11 tools=yes'. This binary would be the whole game engine in itself, so it's the only required thing to have a usable Godot engine for developers. - /usr/bin/godot-runner(*): To actually play Godot games (especially libre ones that you might want to package, e.g. Minilens[5] or Tanks of Freedom[6]), one only needs a version of Godot built without the editor tools (`scons p=x11 tools=no'). All games can therefore run with the same binary (provided they were designed for the same Godot version). To avoid having to build Godot again for each packaged game, I chose to have this -runner binary that can then be used with wrapper scripts to launch each game (`godot-runner -path /usr/share/games/minilens' for example). Note that the games could be run directly with the editor-enabled `godot' binary, but as it's bigger, it's likely better for players to have a smaller binary. - /usr/bin/godot-server: This is the headless version of the Godot editor (`scons p=server tools=yes'), that can be used to host game servers or to do some editor operations without the GUI (exporting games, importing assets, etc.). One could also package the version without the tools instead (`scons p=server tools=no') but I chose to keep the tools for more flexibility and avoid to have to make two binaries for this. - /usr/libexec/godot/templates/* (or /usr/lib/godot/templates/* on Debian probably): Godot uses "templates" to export game binaries to all supported platforms, which are basically the same as the `godot-runner' binary above, but not only for the same platform and architecture as the host system. They are usually built from source or downloaded from the website (building all of them involves a complex buildsystem, especially for iOS, asm.js and android), and installed in ~/.godot/templates (before the question shows up, moving Godot's userdir to XDG_CONFIG_HOME is planned, but was not done for 2.0-stable to avoid breaking compatibility[7]). It is also possible to define a path to look for system-installed templates, hence the above proposed installation path. This would be done by building the `godot' and `godot-server' binaries with `unix_global_settings_path=/usr/libexec/godot' (the "templates/" part is hardcoded, and documented here [8]). The templates need to have very specific names to be recognized, see my above-linked spec file [4]. So far I am only building Linux 32-bit and 64-bit templates in release and debug modes, as I did not want to make the buildsystem too complex. It's less than what most users would need, but it's enough to have a "working" exporter on your distro, so that users can readily export their game in a couple clicks and test them on their host or other Linux hosts. Then there are the SVG icon and desktop file, that's pretty straightforward (I'm not using the upstream SVG icon as I don't like it's "Android app-like" background :), so I made my own without the background). Some binaries (the templates and `godot-runner') are compressed with upx, which is pretty efficient and what upstream does for their official binaries. I'd be interested to hear about experienced packagers whether this would be a bad practice as far as Linux packaging is concerned though. You will probably also find some libraries that you will want to see unbundled. This is a noble wish and I also always try to unbundle libraries in software that I package; for Godot however one has to remember that the binaries produced (at least for the templates) need to run on virtually any Linux distribution, and this pushes us to the limits of "clean" packaging practices (though I obviously chose not to bundle openssl, even if it means that the templates produced on other distros are broken on Fedora, and reciprocally [9][10]). For the main editor binaries though, if you see bundled libraries that could/should be unbundled, I'd gladly work with you to achieve this. Sorry for the lengthy email, but I hope it contains useful information if you have packagers interested in Godot. The packaging method I described above is also not necessarily the best way to package Godot, and I'd welcome any feedback about it too. Best regards, Rémi Verschelde / Akien [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793057 [2] https://people.mageia.org/u/akien.html [3] https://godotengine.org [4] http://svnweb.mageia.org/packages/cauldron/godot/current/SPECS/godot.spec?view=markup [5] https://github.com/KOBUGE-Games/minilens [6] https://github.com/w84death/Tanks-of-Freedom [7] https://github.com/godotengine/godot/issues/3513 [8] http://docs.godotengine.org/en/latest/reference/packaging_godot.html [9] https://github.com/godotengine/godot/issues/1391 [10] https://bugzilla.redhat.com/show_bug.cgi?id=1277662 _______________________________________________ games mailing list games@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/games@xxxxxxxxxxxxxxxxxxxxxxx
