> On Aug 29, 2016, at 11:02 PM, Jesse van den Kieboom <jessevdk 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.
Me, too.
In my opinion the big problem would be with the non-GNOME "system" dependencies, such as libjpeg and other image libs, the network/crypto stack, etc. The mainstream jhbuild modulesets have all these dependencies listed as <systemmodule>s, whereas we have a bunch of tarballs pulled from various locations on the internet. These tarballs are a thorn in my side because 1) they are a lot of work if you need to update them and 2) maintaining them is duplicate effort with Homebrew, MacPorts, etc.
At one point I investigated making a Homebrew backend for <systemmodule> so we could jettison all our maintenance work on these dependencies, but as far as I could tell, Homebrew cannot give you a mapping from file name to package name for packages that are not already installed. (And <systemmodule> requires looking up packages to install by pkg-config file, C header file, or executable in the path [1].)
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 found things improved dramatically in the past few years. By the time I got involved it was not "anti" but "indifferent", and that has changed to "pro" over time. Some MacPorts maintainers have gotten more active with submitting patches as well. At one point they were even talking about setting up a Mac buildbot for WebkitGTK, though I don't know what came of that.
However, I don't know how recent versions fare on OSX. I understood they were going to make the GL texture mapper mandatory in 2.10, which would require some porting on our part. Spending hours building Webkit isn't fun, and now that we have pinpointed a version in our modulesets that works with relatively few patches, I'm not really motivated to keep updating it.
I'm fairly certain that Xcode 7 would be needed to build their current release -- which would be Apple's fault, not WebkitGtk's.
At least 6.3 is definitely needed, 6.2 has a compiler bug that versions as far back as WebkitGTK 2.4 will trigger.
Regards,
Philip C
