WebKit2-GTK: quartz VS XQuartz

Mojca Miklavec mojca at macports.org
Mon May 9 01:00:58 PDT 2016

On 8 May 2016 at 11:19, Andrea Giammarchi wrote:
> Like I've said, telling users they need to wait at least one hour to
> install and build gtk3 +quartz and webkit2-gtk +quartz due lack of pre built
> version

There are two options:
(i) Switch the default from x11 to quartz
(ii) Provide binaries for both x11 and quartz

The first option is problematic because a lot of software doesn't work
without X11 (assuming that GTK implies X11). If MacPorts switches to
Quartz, all that software will be broken and it would be even more
pain to explain to users that they need to switch to X11 just to get
the software from a broken state to a working state (and they would
also have to compile equally long). Now only those who want a better
user experience have to switch.

In theory there is also:
(iii) allow co-existing support for quartz and x11 (at least for gtk3;
I'm sure this is not possible for wxWidgets for example)

So at the moment we could consider different options for (ii). These
are for example:

(a) Provide support for resolving dependencies automatically (some
work has been done during GSOC 2015, but it has not been finished
yet). Then the required binary packages would be built automatically
on the buildbot (as soon as one package would request "gtk3 +quartz").

(b) Provide more hardware to set up a separate buildbot with "+quartz"
being set by default. This means 6 additional virtual machines running
on Apple hardware. That's not trivial, at least not at the moment.
(Does anyone have extra hardware lying around? It has to be reasonably
fast to catch up with all commits though. If so, we could in principle
play with an unofficial buildslave building packages for +quartz.)

(c) Modify the existing buildbot setup to perform (very) dirty tricks
to build support for +quartz (for example: build packages, deactivate
them, modify the default variants to add +quartz, build packages
again, deactivate them, set the default flags back).

It's also true that if binary packages for Quartz were supported,
there would probably be more incentive to fix the broken software.

But unless you have concrete solutions for any of the points mentioned above ...


More information about the macports-users mailing list