On Dec 18, 2012, at 6:11 PM, Behdad Esfahbod <[email protected]> wrote:
> On 12-12-18 09:04 PM, John Ralls wrote: >> >> On Dec 18, 2012, at 5:48 PM, Behdad Esfahbod <[email protected]> wrote: >> >>> On 12-12-18 08:40 PM, John Ralls wrote: >>>> >>>> On Dec 18, 2012, at 3:12 PM, Behdad Esfahbod <[email protected]> wrote: >>>> >>>>> On 12-11-04 11:22 PM, John Ralls wrote: >>>>>> On Nov 4, 2012, at 4:24 PM, Behdad Esfahbod <[email protected]> wrote: >>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> I think Matthias / Owen better know the answer. We used to store >>>>>>>> pango.modules in /etc, but I think Matthias moved it to lib (which is >>>>>>>> the >>>>>>>> right place anyway). Quite possible that some places were not >>>>>>>> properly updated. >>>>>> Umm, actually, it's your change [1] from last March that's the problem. >>>>> >>>>> I think I pushed out a fix today. Can you try? >>>>> >>>> >>>> That's actually a different problem than the one I was talking about (and >>>> I went ahead and fixed that one a couple of weeks ago). I'd been working >>>> around this one with PANGO_LIB_DIR, but I'll reconfigure and try this out >>>> in a couple of days. >>> >>> I see. Ok, please just push whatever you need to fix it, as long as it's >>> not >>> a BIG HACK. >> >> It's >> http://git.gnome.org/browse/pango/commit/?id=69b07369009d3337b1ec2c97e397a2ece9bbab6c >> >> I don't think it's a hack at all, it just sets the load path to >> lib_dir/PANGO_VERSION/modules/foo, where the modules actually get installed, >> instead of /etc/pango, which is where module_file_dir points to. > > Ok, so it's getting more complicated. The idea of resolving non-absolute > paths was that the path would be relative to the file being processed, which > can help in relocatability. But what you're suggesting is different. Let me > see if I can get my head around this. OK, I've dug into the whole process a bit more, and there's another, older, change [1] that comes into play as well. It's what introduced PANGO_LIBDIR. But it doesn't quite work because it's used at runtime only to find modules.cache, which has absolute paths if it's created by pango-querymodules (which also uses it, so you could sort of get there by setting PANGO_LIBDIR and running pango-querymodules --update-cache every time you relocate your package). ded299 changes things a bit so that if the path is relative it looks for a modules directory in the directory containing the file being processed. Good for modules.cache, not so good for pango.modules unless $PANGO_SYSCONFDIR and $PANGO_LIBDIR happen to point to the same place or the builder managed to pass --sysconfdir with the right path to configure. That's unlikely because of the module versions, but I'll concede that it's possible. So I've changed it so that relative paths in pango.modules are relative to what pango_get_lib_subdirectory() returns, which will be the same path as modules.cache, so that part isn't changed and pango.modules is fixed so long as $PANGO_LIBDIR points to the right place. You've now restored the Apple special case (and made it explicit as well, which is good because it makes it less likely that anyone will break it in future). What can we do to make it better still? Well, I think using XDG variables instead of private ones would be an improvement. Does all of this gyrating with text files listing the modules really get us anything, or would it be less trouble to just go to the modules directory and load everything in it? Regards, John Ralls [1] http://git.gnome.org/browse/pango/commit/?id=e94a21a9b52a5b9f9e4a5f1e19f9c84a16bf2838 _______________________________________________ gtk-i18n-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
