OpenXRay
Support running from the build tree without setting LD_LIBRARY_PATH
By using rpath on Linux/BSD we bake the library search path right into the ELF binaries. This relieves the user from the need to set the LD_LIBRARY_PATH environment variable, which is often overlooked when running from the build tree.
The rpath used for the build tree is different than the path used for the installation, in the build tree we use $ORIGIN which will add the executable folder to the search path reflecting the behavior on Windows. This means the build tree is moveable and you could simply copy it to the $fs_root$/bin folder if you'd like to keep the same file structure as the original game. By also restoring the ability to use the fs ltx from the working directory it becomes possible to run OpenXRay in the same way you would on Windows.
When running make install the rpath is automatically rewritten by CMake to installation prefix so that the libraries can be found regardless of the installation prefix. This is the first step towards allowing OpenXRay to be installed to any prefix including /opt.
Currently I think using LD_LIBRARY_PATH is much easier than your code changes, for example we'll need to call dlopen instead of SDL_loadObject adding complexity like this. Is using of LD_LIBRARY_PATH really so bad? Can't we restore the ability to use fs ltx from the working directory without rpath using (by means of LD_LIBRARY_PATH)?
Is using of LD_LIBRARY_PATH really so bad? Can't we restore the ability to use fs ltx from the working directory without rpath using (by means of LD_LIBRARY_PATH)?
If we don't do it as proposed in this pr, the easiest workaround is to write a launcher script that sets the LD_LIBARY_PATH and passes the correct value for the -fsltx option.
Currently I think using LD_LIBRARY_PATH is much easier than your code changes, for example we'll need to call dlopen instead of SDL_loadObject adding complexity like this.
The complexity of setting LD_LIBRARY_PATH is not expressed in the code, but that doesn't mean that it doesn't add complexity. It's just complexity that the user has to deal with instead of the engine. I think the added code required to call dlopen directly is a small price to pay for the benefit of not having users deal with the complexity.
If we don't do it as proposed in this pr, the easiest workaround is to write a launcher script that sets the LD_LIBARY_PATH and passes the correct value for the -fsltx option.
Such a launcher script already exists in the repository: https://github.com/OpenXRay/xray-16/blob/dev/src/xr_3da/xr_3da.sh
We can delete that script after we make this change, saving on code complexity there.
Disclaimer: this can be bikeshedding, that's up the project leaders.
It's just complexity that the user has to deal with instead of the engine.
I agree to that statement. But user should be able handle that complexity easily because he is a developer, not a random guy. The fact is that using rpath instead of LD_LIBRARY_PATH does not add new value to OpenXRay. It is just another way to repeat the current behavior. And additional platform specific code when we already use crossplatform SDL library really smells, as for me. But using fsltx from the current directory can be really handy.
I agree to that statement. But user should be able handle that complexity easily because he is a developer, not a random guy. The fact is that using rpath instead of LD_LIBRARY_PATH does not add new value to OpenXRay.
There are plenty of random people compiling from source and it's still something you have to figure out that it's necessary. So even for experienced devs, it's just one less thing you have to think about.
And additional platform specific code when we already use crossplatform SDL library really smells, as for me.
I think this is the main point you're making. Personally I don't think the SDL abstraction is very valuable here, it doesn't even deal with the file extension problem. We already offer our own abstraction, so the benefit of using SDL here is very minimal. Cross-platform libraries are a powerful tool for cross-platform compatibility, but I don't think that means all platform-specific code is necessarily bad, as long as it's properly abstracted.
