trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged
|
Re: The Inevitable Patch (+3)
Wait, the install didn't prompt to uninstall the previous version first?
Anyway, there was basically three reasons to have the wrapper:
* Help the game locate itself by setting the current working directory
This isn't actually necessarry. The executable can find its own location by reading /proc/self/exe, which exists on all Linuxes (except possibly some very stripped-down server ones maybe, but you don't play games on those), and failing that, argv[0] is usually enough. Actually, DROD has never relied on the current working directory for finding its files, so if anyone had problems with this they'd have problems already. Taking this away had no effect at all after the other problems were solved.
* Set the path for xdg-open.
DROD uses xdg-open to open the default web browser from the buy link in the demo or the external links in the help files. Usually xdg-open is already installed on modern distros, but a fallback is provided in case it isn't, and we need to set the path for that. However, since xdg-open is launched from inside DROD, the DROD executable itself can set this path, using its own location as a base as explained above. No need to do it before DROD launches.
* Set the path for libraries.
DROD comes with its own set of libraries that have been verified to work well with DROD, so that first of all, people don't have to install any prerequisites before they can play the game, and second, if they have a buggy version of a library already installed (which has happened sometimes), DROD will still use its own version which works fine. This was the biggest reason for the wrapper script, as previously I didn't know any way around it -- since libraries are loaded before the executable actually starts running, you can't set this path in the executable itself (unless you dlopen everything, but that's not very convenient and means function pointers everywhere). There is a property you can set in the executable itself, called RPATH or RUNPATH, that is used for this purpose by the linker to set the path before loading libraries, but this path has to be either absolute, meaning DROD could only be installed in a fixed location (or getting the installer to fiddle with the bits in the executable, which isn't exactly trivial), or relative. Problem is, relative is relative to the current working directory, which can be anything unless you set it first (in a wrapper script, say), so this wasn't terribly useful. But then one day I found out about '$ORIGIN'. The linker actually supports macros in the RPATH, and $ORIGIN is one of those, resolving to the path of the executable. So, setting the RPATH of the DROD executable to '$ORIGIN/Libs' means it will look for libraries in the Libs subdirectory where the executable lives, exactly what we needed. So the wrapper script was no longer needed for this either.
With no more reason to have the wrapper script, might as well remove it. This has the additional bonus of a slightly simpler install script, and no more chance of someone accidentally screwing things up by running the executable directly in stead of through the wrapper.
|
. So no problems then?
