> On Aug 29, 2016, at 11:02 PM, Jesse van den Kieboom <jesse...@gmail.com> > wrote: > > I was wondering if there is still a large need to keep a complete separate > jhbuild moduleset setup for OS X. I don't know if this has been discussed > before, or if there was any attempt made to converge on a single repository > of modulesets. It seems to me that as OS X support has been improving over > the years, that it would be worth trying to get rid of the parallel > modulesets that need to be maintained. > > Is it mostly a question of all the patches that are being maintained > separately? Would it be possible to merge this into the jhbuild modulesets? > As far as I know, windows ports are using regular jhbuild. And with "<if > condition-set..." it's possible to conditionally change things when > targetting OS X/quartz.
Jesse, I don't think it's been discussed before, but I do think about it from time to time without actually doing anything. Have you tried bootstrapping and building with the jhbuild modules? I haven't, but I think Emmanuele Bassi does. There may be an issue with building on/for older OS X versions. I'm still targeting 10.5 as a minimum for the current stable series of Gramps and GnuCash. I intend to increase it to 10.7 and drop PPC builds on the next major release of each. For the jhbuild modules Emmanuele is pretty adamant that Gtk should support only the latest release. That might cause conflict in the future though I think only one of the current patches has to do with old compilers (the memory magazine patch in GLib, which works around the broken llvm-gcc in Xcode 4.3). There are a couple of places where versions matter: Bison and libffi, but I think that the newer versions both work for 10.7 and later, and I haven't automated the old-version workarounds for either of them. The Gtk patches are all about indecision about handling mouse events and dialog boxes in the event loop. For the latter see the recent discussion between Paul Davis and Owen Taylor in gtk-dev showing that it's no closer to resolution after 6 years. Having the patches in a quiet out-of-the way project (gtk-osx) is IMO safer than out in front where the Gtk core devs might notice them, and I'm pretty sure they'd be instantly reverted if I pushed them to Gtk. Then there's webkit. We're way behind on that because of the immense number of patches involved and the anti-mac attitude on the WebkitGtk team. That might have gotten better lately, I haven't tried. Maybe Phil could comment on that. I'm fairly certain that Xcode 7 would be needed to build their current release -- which would be Apple's fault, not WebkitGtk's. Regards, John Ralls _______________________________________________ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
