`getResoucePath` not finding correct path
LB-- opened this issue · 9 comments
getResourcePath does not find the correct path on all systems. I would also like to know what it is intended for - is the working directory not suitable for finding resources?
That name of that function is a bit of a misnomer that I never fixed. It retrieves the absolute path of the application executable on all major OSs (I initially intended for that function to return a path to the resources, this was before I decided to use a config file to do that). This path is then used to open config.json, which is what holds the relative paths to resources and game data.
The reason I did this is because in *nix operating systems the working directory of the running application is not necessarily the directory the executable is located in (even when not running the executable from the terminal). Therefore, the only way to guarantee that the application can find config.json is to return the absolute path of the executable, because simply feeding it a relative path may or may not work.
This is also why I mention that the executable must be located in the same directory as config.json. Otherwise the program will segfault (exceptions aren't handled very elegantly yet). If the application is crashing upon start on your end, this is most likely the reason - I've tested this function on OS x 10.7, Windows 7, and Ubuntu.
The reason I did this is because in *nix operating systems the working directory of the running application is not necessarily the directory the executable is located in (even when not running the executable from the terminal).
It is the same way on Windows and other platforms, as it should be. The user should be able to choose whichever working directory they want for the program. If you want the working directory to be the same place as the program, just cd into the directory the program is in ;)
Therefore, the only way to guarantee that the application can find config.json is to return the absolute path of the executable, because simply feeding it a relative path may or may not work.
It is user error, you shouldn't deal with that case.
If the application is crashing upon start on your end, this is most likely the reason - I've tested this function on OS x 10.7, Windows 7, and Ubuntu.
For @ne555, he has to place the program in a different directory than the config.json file in order for it to find it.
On almost all operating systems I know, simply running the program from your directory browser will set its working directory correctly. You can use the console or a shortcut on Windows to start it in a different working directory, e.g. if you wanted to easily run the program with different graphics and configuration without having to swap out files or copy the program file.
Remember: wrong working directory is user error ;)
On almost all operating systems I know, simply running the program from your directory browser will set its working directory correctly.
In some versions of Linux and OS x starting the program from the directory browser sets the working directory to ~, which is the user directory. So the function may not be necessary for Windows platforms, but it is definitely necessary for others. This is why I made that function :P
Ah, OK. Well, in that case how about checking if config.json is in the working directory and if not then try the directory containing the program? This would allow starting it in a different working directory with a different configuration, and would also account for if its working directory is not correct.
That could work as well.
We could also make the function set the working directory too, I think. Although I don't know how to do that in OS x. OS x API is weird as hell. So it could check to see if ./config.json exists, if it doesn't, then find the absolute executable path and set the working directory to that.
I think that might be a good route to take, because I can't think of a reason we would want the working directory to be anything other than the executable directory.
I can't think of a reason we would want the working directory to be anything other than the executable directory.
Two folders with different config.json, graphics, etc. and you don't want to constantly update two identical executables.
EDIT: Also,
http://www.boost.org/doc/libs/1_53_0/libs/filesystem/doc/reference.html#current_path
I think that's over complicating it then. If we want two different config files we can title them differently and keep them in the same directory. Graphics, sounds, etc; it doesn't matter where those are put, because config1/2/3.json will direct to them.
EDIT:
if you mean for debugging/testing purposes, that makes more sense, though. Launch the application from a different directory to test out a config set.
Yes, I mean for debugging and testing purposes.
Also, the link I posted above is only in boost currently - it is planned to be in C++11 TR2:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html
Yeah, filesystem isn't yet in the current C++11 standard.
I'll work on changing that procedure up then. Your points make a lot of sense.