Make Lix system wide installable (following the FHS)

[akien-mga]

I'm looking at packaging Lix for Mageia, and I would like to be able to install it system-wide following the FHS and policies in Linux distributions.

Basically this would require to make it possible to:

• install the binaries in $(prefix)/games or $(prefix)/bin
• install the game data in $(prefix)/share/games/lix or $(prefix)/share/lix $(prefix) being by default /usr/local but with a possibility to override it (for distro packaging, we use /usr).

Providing install instructions in the Makefile would be a nice feature too, but this would come in a second time, since some code tweaking would be required first to be able to support different rootpaths than "./" and "../". Ideally the rootpath would be retrieved from the "make" call (e.g. "make PREFIX=/usr LIX_DATA_DIR=share/games/lix") and hardcoded in src/other/globals.cpp.

Support for additional rootpaths for e.g. user-made content and replays would be nice too (preferably in $XDG_DATA_HOME/lix i.e. ~/.local/share/lix).

[SimonN]

Hey,

sorry for the late reply.

On Sun, 2014-08-17 at 06:43 -0700, Akien wrote:

I'm looking at packaging Lix for Mageia, and I would like to be able to install it system-wide following the FHS and policies in Linux distributions.

FHS-conforming installation has always been some long-term goal for Lix. Most of my core userbase likes everything in the same dir, so FHS-installation has never been important.

Many thanks for considering the packaging -- I'll push the feature's priority, but I'm sorry for not doing this immediately. I'm very busy IRL now, but expect to come back to the project after a couple months or when I feel like it.

Like you hint at, I'm envisioning a virtual file system inside Lix. The in-game level browser should merge the installed levels in /usr/something with a user's Lix directory in ~/something.

  * install the binaries in $(prefix)/games or $(prefix)/bin
  * install the game data in $(prefix)/share/games/lix or
    $(prefix)/share/lix $(prefix) being by default /usr/local but
    with a possibility to override it (for distro packaging, we
    use /usr).

Providing install instructions in the Makefile would be a nice feature too, but this would come in a second time, since some code tweaking would be required first to be able to support different rootpaths than "./" and "../".

I will keep all of this in the back of my head, thanks!

Best regards Simon

[akien-mga]

Hi Simon,

Could you make progress on this topic?

Cheers

[SimonN]

It's still on the radar. I have old code started years ago for this, it still rebases nicely onto the current codebase.

I'll be busy for a couple weeks with university now, after that I should have time again. Continue to nag me occasionally. :-)

[AMDmi3]

nag :) I too really need this for FreeBSD port.

The main part of this task is actually using dotdir for store volatile data (config, savegames etc.). Everything else (installation, data path fixing) I can do myself, but I'd really prefer dotdir-related stuff implemented upstream so it won't change with the next update making users lose their data.

[akien-mga]

nag+ ;) I'm still quite interested to package Lix for Mageia :)

[SimonN]

tl;dr: I'm weighing necessary work for this against deferring to the D port, which will be feature-complete in 6 months.

I have been pushing the D/Allegro 5 port of Lix pretty hard in the past 2 months. It's been way more fun than fixing things in C++ Lix. Also, C++ Lix, due to Allegro 4's age, has runtime problems with several people. These problems unfixable without changing the lib used.

Right now (towards end of January 2016), the D port is 90 % finished with singleplayer, 80 % with the singleplayer-accompanying menu structure, and I haven't yet started editor and netplay. I came up with a good 15,000 lines of D code in slightly less than a year. This will probably turn into something between 20,000 and 25,000 when it's all done. (D makes for slightly shorter code than the 27,000 LOC of C++.) I estimate this to take a bit over 6 months until I can recommend people to treat the port as the default version.

The D port comes with much improved visuals, in particular support for arbitrary resolutions and scalable GUI. Unless the C++ screen is scaled by an integer amount, the C++ version looks downright ugly in comparison.

After all the years I've been pouring in the game, never announcing Lix on larger websites in fear using of outdated technology, I'm a bit reluctant to "waste" a one-off announcement right now, when a much improved version is less than a year away.

The necessary work for this issue (system-wide paths, and a virtual file system inside Lix) is a little bit more than expected, and would take a chunk of development time away from D Lix. FHS-friendliness can then become a feature of the D port.

Screenshot of D Lix Download D Lix binaries for Windows or Debian 6

[SimonN]

C++ Lix is discontinued in favor of D/Allegro 5 Lix, which allows for installation according to the XDG basedir spec: It looks for data both in /usr/local/share/lix and /usr/share/lix, reads/writes to ${HOME}/.local/share/lix, and the binary can sit wherever it likes. See the D Lix file doc/build/package.txt for more info.

@akien-mga, @AMDmi3: It's now 3 years after the issue got opened. I owe you one. >_>

Are you still interested in packaging Lix? Is it still easily doable being written in D? Would the FHS-support enough as-is, or would you like more flexibility? I still read all github issues and sit in irc.quakenet.org #lix.

I'd suggest to wait with actual packaging until I release 0.9.0 by end of week. I have important physics changes on the backburner that I will merge in the next few days.

[akien-mga]

Are you still interested in packaging Lix? Is it still easily doable being written in D?

I'm definitely still interested, though it being written in D will indeed be a difficulty, as there is no D compiler packaged for my distro yet. But I may look into existing gdc and ldc packages of Debian to see how hard it would be to enable them in our GCC or LLVM stack, and/or if dmd can easily be packaged from scratch.

Would the FHS-support enough as-is, or would you like more flexibility?

It's already quite good. For Debian-based distros as well as Mageia and a few others, games are typically packaged in /usr/share/games/<name>, which is recommended but not enforced in the FHS. So if you could also check this path, that would be perfect, otherwise I'd expect that it would still be quite easy to patch for distros that want to use it.

[SimonN]

Thanks for the quick reply!

I've just test-built D Lix 0.8.5 with LDC. I got only a single compile error that will be easily fixable. LDC sounds like a good choice because it produces the best-optimized binaries among all D compilers.

I'd like to offer free compile-time choice of installation path, then. Unlike in C, we can't pass arbitrary strings as macros during the a D build, but there is string import (textual inclusion): A packaging script could write the path into a specified file, then Lix string-imports that.

[akien-mga]

Yes, a compiler define for the install path would be just fine (with maybe a default value of ${install_prefix}/share/${project}, so that it works out of the box for most cases).

[SimonN]

D has versions (boolean flags that you toggle by compiler switch), but no way to pass strings directly from the command line (it doesn't support C macros at all).

I concluded that the path must somehow be configurable right inside the source. The file D Lix 0.8.8 doc/build/package.txt should explain it all. If you feel this is too clunky, we can try to find another solution.

This is not yet the 0.9 with the planned physics change (still some back-and-forth with tileset designers). I'd still wait for 0.9 before releasing a package. But the support for package maintainers in 0.8.8 is already what I've planned for 0.9.