Amos from Itch has written a guide to distributing self-contained Linux builds

well, he could just point out xdg-app.

For the launder script, there are some side cases where:

SCRIPT_DIR=$(readlink -f $0 | xargs dirname)
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${SCRIPT_DIR}/lib"
cd "${SCRIPT_DIR}/bin"

$() is bash specific I think and there is absolutely nothing wrong with ``

btw. do you use
#!/bin/bash
or
#!/usr/bin/env bash

[...]SCRIPT_DIR=$(readlink -f $0 | xargs dirname)"[...]

My favourite has been the following, for a number of years:
DIR="$(dirname "$(readlink -f "$0")")"
Same thing really, I just like the non-piped approach.

[...]

$() is bash specific I think and there is absolutely nothing wrong with ``

btw. do you use
#!/bin/bash
or
#!/usr/bin/env bash

Very true. I prefer to just require bash instead of targeting sh in general - less surprises down the line in case I forget some incompatibility issue.

I generally use /bin/bash. No real reason other than I've never had issues with it.

At the time of this writing, 32-bit processors are becoming rarer, but 32-bit operating systems are still a reality. Distributing both 32-bit and 64-bit binaries is a small effort that prevents a lot of headaches.

I'd say no. If developers are constrained they should drop 32-bit builds and only release 64-bit. Otherwise they'll have to deal with a lot of hidden issues, like the infamous large XFS partition bug. Those focused on gaming today don't use 32 bit OSes anyway, and non capable of 64-bit PC hardware doesn't exist for years already.


Last edited by Shmerl on 25 Mar 2016 at 3:07 pm UTC

they shouldnt be doing .debs anyway...

Not sure this is inside the scope of this particular guide but using XDG_* vars to store game profiles/saves/config etc should be noted somewhere

Don't forget that something like a Raspberry Pi may not be 64bit, but could be a target audience for some games, and is a flavour (of sorts) of Linux.

But the Pi has an ARM CPU, so it's a completely different architecture anyway.


Last edited by DrMcCoy on 25 Mar 2016 at 7:14 pm UTC

Don't forget to also export LC_ALL=C
It sometimes confuses engines if not set. And I second the XDG_* suggestion. I hate apps that create their own .hidden_directory right in my home directory.

Don't forget to also export LC_ALL=C

I'd argue that this should only be done when necessary. Game developers should learn to make use of the locale settings instead of ignoring and stumbling on them.

Don't forget to also export LC_ALL=C

I'd argue that this should only be done when necessary. Game developers should learn to make use of the locale settings instead of ignoring and stumbling on them.

While that's true, I still see a lot of games (particularly Unity ones) that seem to trip over this issue. XDG does are also somewhat of a locale issue, and there is a lot of games that confuse scancodes and keycodes, or more generally, that have strange defaults on non-qwerty keyboards.

So, I would say that overall, developers have a problem with internationalization (or, at least, foreign configurations), and should also do some QA outside of their country (ie. on the net, not only internally).

At the time of this writing, 32-bit processors are becoming rarer, but 32-bit operating systems are still a reality. Distributing both 32-bit and 64-bit binaries is a small effort that prevents a lot of headaches.

I'd say no. If developers are constrained they should drop 32-bit builds and only release 64-bit. Otherwise they'll have to deal with a lot of hidden issues, like the infamous large XFS partition bug. Those focused on gaming today don't use 32 bit OSes anyway, and non capable of 64-bit PC hardware doesn't exist for years already.

Sorry but I'm not aware of all information, I never had any bug in XFS partition since opensuse made as default, I became curious about the bug but the google gave me only old forum posts, then, I need to ask what kind of bug is?