WebKit2-GTK: quartz VS XQuartz

[Mojca Miklavec]

Hi,

I'm sorry for posting the reply to the developer mailing list rather
than the user mailing list where this was originally posted, but I had
a feeling that the dirty details don't interest regular users so much.

On 5 April 2016 at 01:10, David Evans wrote:
> On 4/4/16 1:21 AM, Andrea Giammarchi wrote:
>>
>>  2. wouldn't be better macports experience if quartz backend was also pre-built like it is for the xquartz one?
>>     Installation time is 10x slower than the Homebrew one
>
> This could probably be done, but would require more buildbot resources than we currently have allocated.  Ryan, our
> sysadmin for these issues, could address what it would take to do this.

With slightly modified behaviour of MacPorts we wouldn't even need
additional resources. The buildbot could check if variant +quartz
exists and if +x11 is the default one. And in that case run another
build of the same port with +quartz -x11. That would be easy to do.
The biggest problem at the moment would be the dependencies where
variants cannot easily be imposed (at least not until the dependency
resolving gets fully implemented).

(Another dirty hack would be to do the same check of existence of
x11/quartz variants and if it turns out that this is the case, change
variants.conf on the buildslave to +quartz -x11 before the rebuild of
that port and then change it back after the build is finished.)

The above mentioned trick(s) would only consume slightly more
computational power on ports that offer the choice, but wouldn't
require setting up a zillion new build slaves. But Rainer was working
hard on reimplementation of the buildbot and it would make sense to
wait until his implementation goes live before spending any effort on
the old setup.

(In any case I believe that we would end up with better support for
Quartz if we had those packages prebuilt and if errors were reported.)

> However, there is another way.  gtk3 has for some time supported the concept of building with multiple backends
> simultaneously (as cairo and pango do).  So we could look at having a single gtk3 +quartz+x11 default build.  I'm
> looking at what the consequences of this would be on gtk3's dependent ports as a background task at this point, but it
> should be doable.

Wow! This would be awesome indeed and would solve just about 99 % of
the problems I had with some ports (because I cannot rely on existence
of quartz support nor easily test things / make quartz default for
ports where this would be supported). Whenever I want to test
something, I run into a huge number of conflicts because of many ports
that have been built against gtk3 +x11 and I lose the motivation to
push my MacPorts installation to an inconsistent state.

If you can figure that out, I would be enormously grateful for that.

> Unfortunately gtk2 does not support this ability and probably never will.

That doesn't really matter. It's not like gkt2's support for quartz is shining.

Mojca