On Sat, 2005-11-12 at 16:00 +0100, Han-Wen Nienhuys wrote: > Han-Wen Nienhuys wrote: > > The most efficient way of accomplishing this seems to be expanding > > environment variables in > > > > char **pango_split_file_list (const char *str) > > > > and somewhere in the config file parser, eg. in pango_scan_string(). > > Hi, > > a patch to do this is, is at > > http://savannah.gnu.org/cgi-bin/viewcvs/lilypond/installers/macos/PATCHES/pango-env-sub?rev=HEAD&content-type=text/vnd.viewcvs-markup If you want your patch not to be lost, you need to put it into Pango bugzilla (bugzilla.gnome.org ... see README file for details.) I'm not opposed to the idea of expanding environment variables in the config files, but it's not clear to me how environment variable expansion in config files really improves the ability to relocate Pango ... having to write wrapper scripts that set environment variables isn't that appealing. The way it works for Pango under Windows (as I recall) is that in Windows you can get the location of a DLL using GetModuleFileName(). Pango does this, and then does textual replacement based on comparing this to what was compiled into the library. So, if the installed package has the DLL at: c:\Program Files\Pango\lib\pango.dll But the distributed copy things it should be at: c:\PangoBuild\lib\pango.dll Then where Pango would normally look at: c:\PangoBuild\lib\pango\1.4.0\modules That gets rewritten to: c:\Program Files\Pango\lib\pango\1.4.0\modules This is arguably a horrible hack, but if you can figure out how to get the location of the Pango library under OS X, it seems that this would be a lot nicer for end-users than requiring wrapper scripts. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part