Re: [gtk-osx-users] Removal of pango modules

[John Ralls <jralls ceridwen us>]

> On Feb 23, 2016, at 9:25 AM, Christoph Reiter <reiter christoph gmail com> wrote:
>
> On Tue, Feb 23, 2016 at 3:50 PM, John Ralls <jralls ceridwen us> wrote:
> > Hooray! Bedhad said he was going to do that about 4 years ago. I guess it turned out to be harder than he 
> > expected.
> >
> > The problem with just whacking the code out of bundler is that there's no real linkage between bundler 
> > versions and gtk-osx-build versions. How about leaving the code in but making it depend on the modules 
> > being present?
> >
> > Regards,
> > John Ralls
>
> Thought of that as well but I couldn't think of an easy solution there.
>
> (1) Assuming one updates gtk-osx-build the bundling will fail because of the
> modules path in the "<binary>" node [0] in the bundle for the pango modules.
> Removing that line will make create_pango_setup() fail. Not much we can do I
> think.
>
> (2) The other way around, updating the bundler (while keeping the old bundle
> xml) but not osx-build we can handle by either erroring out depending on the
> pango version (pkg-config --modversion pango) and suggesting a newer
> gtk-osx-build or detect if modules are present and still do the
> create_pango_setup()
>
> [0] https://git.gnome.org/browse/gtk-mac-bundler/tree/examples/gtk3-demo.bundle#n72

ISTM the last option, running create_pango_setup() iff the modules are present, is the correct behavior. I'm 
no more enthusiastic about version dependent checks in bundler than I am in configure scripts: They should be 
a last resort only if there's no better way. BTW, that doesn't mean I don't get lazy and use them... I guess 
we need to add an "optional" attribute of some sort to binary and data elements so that the bundler won't 
error if it doesn't find them.

With Gtk+-3.20 around the corner we'll have to update Pango pretty soon, so we'd better get bundler ready. 
I'm inclined to go for a late 3.18 release rather than 3.20.0, though: The early releases seem to always have 
a bunch of portability problems. Speaking of version checks in configure scripts, there's also the stupid 
config check in glib to make sure you're running OS X 10.9 or later which ignores the SDK you use, all to 
protect a little-used notification feature in gio. That needs to be replaced with a header check for 
NSNotificationCenter.

Regards,
John Ralls