Linux: Drop the ".bin" binary suffix (i.e. encode the data path into the binary?)

[akien-mga]

I've started some work on the CMakeLists.txt (I'll push it to my fork soon so that it can be reviewed), and dropping the ".bin" binary suffix is not as straight-forward as it looks like.

Currently the file cmake/config/OpenDungeons.in is used to generate a bash script that runs OpenDungeons.bin with the needed environment variable to let OD find its data:

#!/bin/sh
OPENDUNGEONS_DATA_PATH="/usr/share/games/opendungeons" exec "/usr/games/OpenDungeons.bin" "$@"

If we want to drop the ".bin" suffix (and set the binary name in lower case on Linux if possible), we need to find another way to let OpenDungeons know the location of the data directory (currently defined as OPENDUNGEONS_DATA_PATH here: https://github.com/OpenDungeons/OpenDungeons/blob/development/CMakeLists.txt#L507 ).

Any idea about how this could be done (i.e. how most games do it)? It looks somewhat messy to have a broken (as in, you can't execute it properly) OpenDungeons.bin binary in /usr/games and a script to make it work.

[Bertram25]

Hi @akien-mageia :)

Well, I'll need to have a more careful look at how it is done, but there is something surprising me. Maybe you can tell:

• In what way renaming the binary is preventing the current script from running? (renaming stuff in it apart?) I fail to get it.
• Currently, the code is getting the data path here, for instance:
  https://github.com/OpenDungeons/OpenDungeons/blob/development/source/ResourceManager.cpp#L127

What I saw elsewhere is that usually, such a variable is hard-coded by cmake at compilation time depending on the platform, making the launch script useless.

Example:
DATA_PATH="/usr/share/game/opendungeons" on linux
DATA_PATH="." on windows

...
IMO, it's what we should do.

What do you think?

[akien-mga]

In what way renaming the binary is preventing the current script from running? (renaming stuff in it apart?) I fail to get it.

I think the only reason is that the initial design of this system would be to put both the "OpenDungeons" script and the "OpenDungeons.bin" binary in the /usr/games (or /usr/bin) folder. That's somewhat messy because the OpenDungeons.bin binary can't be run as is, so it shouldn't be in the $PATH; but likewise it's bad practice (or so I've gathered from my packaging experience) to include binaries in data dirs such /usr/share/games/opendungeons.
For packages that come with loads of internal binaries, such as OpenFOAM for example (CFD software), the policy on Mageia is to put those in the "libexec" path, that would be /usr/libexec/$name or possibly for OD /usr/libexec/games/opendungeons.

I have seldom has to use such a trick, since as you said, most project retrieve the data path from the cmake call. So yes ideally, we want a cmake variable that can be set by the user and that determines the location of the game data. Same things for the binary btw, and potentially for additional stuff on Linux (desktop file, icons, man page, etc.).

We'll probably need something along those lines:

set(SHARE_DIR "${CMAKE_INSTALL_PREFIX}/share" CACHE PATH "Absolute path to the shared files system directory")
set(DATA_DIR "${SHARE_DIR}/games/${PROJECT_NAME_LOWERCASE}" CACHE PATH "Absolute path to the game data install directory")

Being declined for all platform in a big old IF(...).

I could take care of the cmake part (I've already started it btw in issue #58), but this needs some tweaking in the code too to hardcode the cmake variable into the code. And maybe add the possibility to use additional data paths for user-made content, such as ~/.local/share/opendungeons?

[Bertram25]

I could take care of the cmake part (I've already started it btw in issue #58), but this needs some tweaking in the code too to hardcode the cmake variable into the code.

I guess this would mean changing the getenv() calls in the resource manager to a plain old define, and make the binary do a cd there when run.

And maybe add the possibility to use additional data paths for user-made content, such as ~/.local/share/opendungeons?

Why not in a second step. But IMHO, this is out of scope for 0.4.9 and this issue. Let's first make a standard & working binary.

[akien-mga]

And maybe add the possibility to use additional data paths for user-made content, such as ~/.local/share/opendungeons?

Why not in a second step. But IMHO, this is out of scope for 0.4.9 and this issue. Let's first make a standard & working binary.

Agreed :-)

[akien-mga]

PR #184 made this issue really easy to solve, I'm on it.