win32 gtk+/dev-c++ question

[Tor Lillqvist <tml iki fi>]

(Cc:ing to gtk-devel-list.)

Tim Newsham writes:
 >   - What kind of magic goes on to translate the /target/* path
 >     into the c:\progra~1\common files\gtk\...   path that is
 >     used by the installer?

Read the code, it is Open Source after all ;-)

What goes on is that when Pango notices that the path from the
pango.modules file equals its compile-time setting, it assumes that
this is a pango.modules file produced by whoever built Pango. It then
replaces that path with the actual one to be used on the machine in
question. (It assumes that the folder structure is a standard one,
i.e. that libpango-1.0-0.dll is in whatever\bin, and that the modules
then are in whatever\lib\pango\1.2.0\modules. (For Pango 1.4.0, the
module folder is lib\pango\1.4.0\modules.)

I.e. it is OK that the pango.modules file contains paths that don't
exist on the end-user machine, as long as the paths it contains are
exactly the one compiled into the Pango DLL, and as long as the folder
structure is correct.

 >   - Is there any override I can use to force it to use my path?
 >     I couldnt find an environment variable for pango which does
 >     this.  Does the win32 port have anything special for this
 >     purpose?

Path to the modules? I don't think there is such an environment
variable, it isn't really needed as you can just edit the
pango.modules file.

However, the path for the pango.modules file (or actually, a list of
file names) can be specified using a "pangorc" file. This file can be
either called pangorc in the etc\pango folder, .pangorc in the user's
home directory, or specified by the PANGO_RC_FILE environment
variable. (Such files, if they exist, are all read.) I haven't
actually used this myself, but from the code it seems that the pangorc
file contains stuff with [section] style headers followed by key=value
style lines. The ModuleFiles key in the Pango section can be used to
specify a list of module list files to use instead of
etc\pango\pango.modules.

All this is probably documented somewhere, ot then not... It is quite
possible that somebody just went a bit overboard with the
configurability, and that the above features aren't really used on any
typical installation on any platform.

 >   - Any idea what the previous version I was using may have done
 >     differently?

Not really.

--tml