GNOME Bugzilla – Bug 678707
Make glade relocatable
Last modified: 2018-03-26 15:25:04 UTC
Created attachment 217114 [details] [review] Patch against 3.7.3 and 3.8.* Currently glade is not relocatable. This patch makes it relocatable. The patch in its current form is not ready for inclusion into the code base. But it can be a starting point and it might be useful to others.
Interesting, I looked briefly through the patch and wish you would elaborate more on exactly what case this is handling. Or perhaps point me to some documentation... I see your patch adds some environment patch checking for GTK_EXE_PREFIX and then builds the paths... what is this case for ? Current status of Glade as far as I know wrt relocatability, is: o it should be working fine on OSX, using the ige-mac-integration packages gets us paths to all needed resources at initialization time o win32 should be working fine since we use g_win32_get_package_installation_directory_of_module() to load our paths, perhaps some system dependent fallbacks should be inserted in places where Glade tries to "load a module by name" without an absolute path. Whatever win32 should be consistent with the build scripts which Dieter Verfaillie provided for us to build in win32. o On standard unices then we are mangled into the "everybody install into the shared build prefix", there is no relocatability with this standard... perhaps your patch forges a way to build relocatable packages on a unice system ? What's the rationale/approach ? You go and find the real path of argv[0] and base all other paths on where the application was forcibly moved ? (and you assume if someone moved the application, then all the libraries and resources followed into a location relative to the application ? is this wise ?)
Anselm, Ping. May I presume that the patch is rejected and this bug a WONTFIX if we don't get a response?
Sorry for the delay, I missed the July post during my vacations ... Thanks for the ping. (In reply to comment #1) > Interesting, I looked briefly through the patch and wish you would > elaborate more on exactly what case this is handling. > > Or perhaps point me to some documentation... I see your patch adds > some environment patch checking for GTK_EXE_PREFIX and then builds > the paths... what is this case for ? > > Current status of Glade as far as I know wrt relocatability, is: > > o it should be working fine on OSX, using the ige-mac-integration > packages gets us paths to all needed resources at initialization time I don't have any experience on OSX. > > o win32 should be working fine since we use > g_win32_get_package_installation_directory_of_module() to > load our paths, perhaps some system dependent fallbacks > should be inserted in places where Glade tries to > "load a module by name" without an absolute path. > > Whatever win32 should be consistent with the build scripts > which Dieter Verfaillie provided for us to build in win32. Win32 is OK > > o On standard unices then we are mangled into the "everybody > install into the shared build prefix", there is no relocatability > with this standard... perhaps your patch forges a way to build > relocatable packages on a unice system ? And that is the case my patch solves. > What's the rationale/approach ? You go and find the real path > of argv[0] and base all other paths on where the application > was forcibly moved ? We ship glade as part of a commercial application, that is intended for code server installation and therefore fully relocatable. On Windows this worked out of the box, on Linux I had to patch glade. (Of course we ship the complete source code for glade and other (L)GPL components, but our customers don't like to recompile.) There are two possible approaches to make an application relocatable - use environment variables - find the real path of the executable (argv[0], proc/self/exe, ...) and base all other paths on the path to the executable. Environment variables are more flexible but you need a wrapper script to set them. Because I need to set many variables for other reasons, I went the way of least resist and used environment variables wherever possible. Only for the bin_dir I use the installation dir of the executable, as computed by the public domain source from Hongli Lai. In order to limit the number of environment variables I tried to stay close to established standards (XDG base directory, GTK conventions). Of course these source changes are not enough for a fully relocatable glade. We also made all libraries fully relocatable and we use rpath-settings of the form "$ORIGIN/relative/path/to/lib". My patch does not include these changes, because we use a build system, that applies these changes after a conventional build. > (and you assume if someone moved the application, > then all the libraries and resources followed into a location > relative to the application ? is this wise ?) This is exactly the scenario in industrial code server installations. Our application is installed on various code servers and served via NFS/CIFS to several thousand clients. I consider my patch as a starting point only, because an average glade user or sys admin is not able to build a fully relocatable gtk installation. But all required patches and documentation are published: https://ep2012.europython.eu/conference/talks/building-an-advanced-python-installation-for-linux-and-windows https://github.com/akruis/advancedPythonInstallation And finally my patch is for gtk2 glade 3.8 only.... Therefore I don't recommend to apply the patch in its current form. But it could be used as a starting point for further development. Unfortunately I can't do it, because our application will stay with gtk2 for a long time.
No open questions here; removing NEEDINFO status
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/108.