[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Relative path in game? SOLVED



Ingo Ruhnke wrote:
On Fri, Oct 13, 2006 at 08:25:17AM -0500, Gianfranco Berardi wrote:

I decided to look at the existing game installations I have. It seems that Sam Lantinga has already solved this problem years ago with his FindPath() script:

http://www.libsdl.org/pipermail/sdl/2001-March/034831.html

I wouldn't call FindPath() a solution, its a workaround that can easily
made to fail. When you for example extract a game to /opt/ and symlink the
binary to /usr/bin/ FindPath() will give you /usr/bin/ instead of /opt/ as
result. The correct way would be to read /proc/self/exe, binreloc from autopackage encupsules that and a bunch of other detection magic:

Well, FindPath() seems better than assuming that your user is using Gnu/Linux or some OS with /proc, right? It seems the most portable solution if your intention is to get binaries to other OS users is to use FindPath(). If you symlink to /usr/bin as you say, why not just change the name of the actual binary? The link in /usr/bin can be game-name, and it can point to the FindPath() script, which can just be named runApp or something similar. And it will just find the location of the binary, which is game-name.bin or some other name. Wouldn't it work just fine then? Obviously it is still a gotcha for someone who doesn't know better, but it should work on systems regardless if they use proc or not.


However, as I do more research, I see that the info out there is contradictory. LSB wants one thing, the FHS says another. The first seems specific to Linux-based systems, the second is generalized to Unix-like systems. Or maybe I've read them wrong?

And Frederic's link about using the FHS to hold the data in the correct locations assumes system-wide installation. I'm sure some players will simply extract the file to their /home directory to try it out or maybe they don't want to mess with using privileged permissions just to install a game. If the binary assumes that the data will be in /usr/local/share, for instance, then it seems broken again if the data isn't installed there. And I'm definitely not going to see an easier time of testing if I need to put the data in the correct directories before I can use them.

I have more information, but somehow I am more confused.  B-)

I imagine I could do worse than to follow the example of existing games, though. I just did a "find ./ -name darwinia" from /, and it returned:


./usr/lib/menu/darwinia ./usr/local/bin/darwinia ./usr/local/games/darwinia-demo/darwinia ./usr/local/games/darwinia ./usr/local/games/darwinia/darwinia

I also have .darwinia in my home directory.

When I do
$ ls -al /usr/local/bin/darwinia
lrwxrwxrwx 1 root staff 34 2005-05-13 23:42 /usr/local/bin/darwinia -> /usr/local/games/darwinia/darwinia*


I find that /usr/local/games/darwinia/darwinia uses FindPath, then runs $here/lib/darwinia.bin.x86

There doesn't seem to be one definitive way of solving this problem, so until there is, FindPath() seems good enough.

--
GBGames' Blog, An Indie Game Developer's Somewhat Interesting Thoughts:
http://www.gbgames.com/blog
Staff Reviewer for Game Tunnel, the Independent Underground:
http://www.gametunnel.com