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

[Damjan Jovanovic <damjan jov gmail com>]

On Fri, Apr 15, 2011 at 11:06 AM, Alexander Larsson <alexl redhat com> wrote:
> On Wed, 2011-04-06 at 23:34 +0200, Kean Johnston wrote:
>
>> Last, but by no means least, is the reliance on "compiled" files, like
>> compiled schemas (or in the case of Gtk, icon caches). On UNIX systems
>> where things are installed in a universally-accessible location, this isn't
>> a problem, but on Win32, where multiple applications could all include
>> their own private copies of the DLL's, this is a problem. Fixing this is a
>> bit tricky but very doable. Windows does provide two places that are
>> predictable and universally accessible: the registry, and %ProgramData%.
>> The registry is a poor choice except perhaps for location files inside
>> %ProgramData%. The registry is slow, and also imposes some severe
>> limitations on key sizes etc. This can be very easily addressed by
>> compiling Glib with LIBDIR set to something like "%ProgramData%\Glib\2.x"
>> and ensuring that functions like g_file_get_contents() or g_open() all call
>> ExpandEnvironmentStrings() on Win32. This is also a relatively small change
>> and doesn't change any existing API's (although on Win32 it will have a
>> behaviour change).
>
> Things like this is a problem on unix too, as it makes relocatable
> apps/libs hard.
>
> I've long had this dream of perfectly relocatable gnome libraries/apps
> where the executable file itself contained all the information it needs.
> Relocating something like that is trivial (LD_LIBRARY_PATH is all that
> is needed).
>
> The plan I have is to add a resource system to gio, similar to
> http://doc.qt.nokia.com/4.0/resources.html where you describe the
> resources in a file, and during the build this gets compiled and linked
> into a read-only section in the library/executable. Then we'd have an
> API that allows easy lookup of named resources (in a combined namespace
> for all libraries in the app) such that you can easily get inputstreams
> to the data or direct pointers to the data.
>
> This allows all kinds of nice extras, like transparent compressed
> resources (although these will not allow direct pointers) and
> locale-specific versions of resource files. It will also ensure that all
> users on the system map the same resource data instead of loading it in
> each process.
>
> Another aspect is translations. I've been thinking a bit about ways to
> relocate these. We could internalize a copy of gettext into glib and
> modify it to be able to read mo files directly from the binary. Of
> course, this would make the library kind of large, but not larger than
> the current total package size. It would be harder to strip out unused
> translations in an installation though, but I have some ideas that can
> solve this.
>
> Introspection data could also be made part of the shared library itself,
> rather than a separate file. It would just be a custom elf section.
>
> 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.

Damjan Jovanovic