Build dependencies (was: Re: Request: require glib2 >= 2.12)

[John Ralls]

On Mar 2, 2010, at 8:10 AM, Derek Atkins wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>> On Feb 20, 2010, at 10:32 AM, John Ralls wrote:
>> 
>>> 
>>> WebKitGTK is another dependency that we need to assess, I think. They don't actually have a declared "stable" release yet, though they have a quasi-stable 1.15 branch. Their announced plan was to have a stable 1.2 out this summer, but their list has been  very quiet lately, so I'm not sure how they're doing on that goal. I doubt very much that they're worrying much about backwards compatibility, though, and if WebKitGTK requires gtk+-2.20, our efforts at backwards compatibility are futile. Does RHEL5 support building WebKitGTK -- or provide an RPM? 
>> 
>> Well, WebKit has fiddled their configuration so that Gtk will only work with X11. This is probably OK for now, I can continue to use 1.12 as long as they keep it on their website (or I suppose I could re-host it somewhere if they don't). But perhaps we should look into Gecko as the rendering engine for Gnucash-2.6. It's too bad, because Phil put a lot of work into WebKitGtk.
> 
> That's unfortunate.  If we fiddle them back will we be able to get it to
> work with Cocoa again?  Or are they explicitly NOT supporting Gtk-Cocoa?
> 

The way it's now set up, they completely ignore the --target=quartz configure option. If Gtk+ is detected, it requires libXt, which of course won't work with quartz. Fink will be fine, MacPorts will be fine as long as it's set up to build for X11, but it won't work for Gtk-OSX. 

You might recall that I filed a bug against WebKitGtk on this last summer, and got the rather tart reply that "we don't support Quartz for plugins" and a changeset that removed the distinction between MacOSX and other Unices in the file that caused trouble. I managed to patch around that (which is why I'm able to ship with WebKit 1.12). They've done more work, though, to extend the exclusion of Quartz and my patch doesn't apply against 1.1.15 (nor git master). 

I could probably write a new patch to get 1.1.15 working, but it seems to me that it's not really a viable long-term strategy.

Regards,
John Ralls