Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)

[John Ralls <jralls ceridwen us>]

On Apr 15, 2011, at 6:01 AM, Alexander Larsson wrote:

> On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote:
> 
> 
>>> Of course, some files are inherently made to be external, read by 
>>> other
>>> applications. Such files are hard to relocate, like application
>>> icons,
>>> desktop files, icon themes, widget themes, plugins, custom mimetype
>>> descriptions, dbus service files. I don't really know what to do
>>> with these.
>> 
>> A library can discover its current path by calling dladdr() on *nix
>> and MacOS X, and GetModulePath() on Windows. The library then loads
>> resources relative to that path.
> 
> Yes, thats is doable on many OSes, but its still kinda ugly, as it
> implies that the relative paths to the files are kept, and thus implies
> that things are stored in typical unix style hierarchies, etc. It is
> much cleaner to just have a single file.
> 
> It doesn't solve the inherently hard things listed above though, because
> the problem for them is that *other* things than the library itself
> loads these files.

ISTM that it's cleaner and more broadly applicable to use something like binreloc (sadly no longer being developed, but widely copied and used in unix applications), where the paths to various resources can be configured at runtime in whatever way is appropriate for the system. We do this with Gnucash and it works well, though some of our dependencies don't and we have to resort to hacks to work around their limitations. 

Regards,
John Ralls