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

[Kevin Fox <Kevin Fox pnl gov>]

On Fri, 2011-04-15 at 06:01 -0700, 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.

Usually the tool used to solve this problem though is a file system.

An appdir like structure is a good compromise between other things
needing to easily access the data and having all the stuff in one
location that can be easily copied and moved around.

Another option might be to simply tar (but not [bg]zip) up the library
and related files and change the dynamic linker to mmap the correct
subsection of the file instead of the whole thing.

Kevin


>