GNOME Bugzilla – Bug 658772
Directory paths for resource directories are hard-coded
Last modified: 2011-10-15 20:04:05 UTC
Directory paths for GTK_DATADIR, GTK_LIBDIR, etc. are hard-coded to prefix during configure. Gtk applications installed in application bundles need to be relocatable and to find the paths to these directories dynamically in Quartz, just as they are in Win32.
Created attachment 196223 [details] [review] Implement dynamic directory paths, same as for Win32
Doesn't this break if GTK+ is not used as a bundle? I don't fully understand the comment "becuase mainBundle paths point to the bin directory in that case" which bin directory does it talk about? The bin directory in the prefix? If I have GTK+ installed in /source/prefix/ and have a test application /Users/kris/mytest, doesn't module loading start to fail? Module loading relies on LIBDIR to be set correctly. Another idea could be to make this a compile-time option that is set during configure.
It works fine without a bundle: NSBundle mainBundle returns the executable's directory if it isn't in a bundle [1]. You're right that it doesn't work if the executable's directory isn't $PREFIX/bin. Making it a configure option is easy. Is it good enough? --enable-quartz-relocatable-paths? Otherwise I can replicate the Win32 hack (where the functions must run before the redefinition of the macros) and test for the existence of a file in the bundle path, then for the file on the compiled path, and if that fails... do what, return NULL? That would probably crash. Note that setting $LD_LIBRARY_PATH helps with loading modules, but there isn't an equivalent for locales or other data -- and this came up because Gtk wasn't finding its translations in app bundles. [1] http://developer.apple.com/library/mac/#qa/qa1436/_index.html
We could do some run-time detection to see if we are running from a bundle or not and set the paths based on that. I am a bit afraid that this might become too complex or error prone. IMHO, a good thing about the configure option is that it gives a clear choice; either you compile GTK+ for usage in a bundle or for system-wide installation.
Committed with a configure option (--enable-quartz-relocation) to gtk-2-24, gtk-3-2, and master.
The pushed patch doesn't follow the coding style, and it leaks the returned strings.
Created attachment 199026 [details] [review] Fixed formatting, make returned variables local static so that they don't leak Is this more to your liking?
That looks just right, thanks :)
Comment on attachment 199026 [details] [review] Fixed formatting, make returned variables local static so that they don't leak Pushed to gtk-2-24, gtk-3-2, and master.