WebKit2-GTK: quartz VS XQuartz

[Andrea Giammarchi]

I understand the combinatory logic of your answer, hence I'm saying quartz
variant should be the default. I don't know why the X11 version is
currently the one, I don't think anyone would visually prefer that these
days and I don't know who preferred that in the past. GTK3 +quartz and
WebKit2-GTK +quartz might be a very useful hard coded exceptions that would
make developers like me happy to have by default. The alternative is
Homebrew or native builds on quarts like the GTK mailing list itself is
suggesting. So again ... why X11 as default? AFAIK everyone is trying to
move away from it ¯\_(ツ)_/¯
On May 7, 2016 6:20 PM, "Ryan Schmidt" <ryandesign at macports.org> wrote:

>
> On May 7, 2016, at 4:51 AM, Andrea Giammarchi wrote:
> >
> > I am not sure why there are no pre-built gtk3 +quartz and webkit2-gtk +
> quartz ports available so, beside which would work better argument, and
> please note in the GTK ML everyone apparently seems to prefer the Quartz
> variant, which is indeed the default one via homebrew, it would be very
> nice to have these two variants pre-built as well, so that mozjs24, ffmpeg,
> and highlight would be the only slow-down ports after a `port install
> webkit2-gtk +quartz` operation.
> >
> > Thanks in advance for considering it, as a user it would be awesome so I
> can stop warning Mac Users that having a good looking GTK3 app requires at
> least one hour via MacPorts due lack of pre-built quartz packages.
>
> Just to answer this small portion of your question: our buildbot setup
> only builds default variants at this time. On most ports that have it,
> +quartz is not a default variant, therefore the buildbot does not build
> them.
>
> This decision probably stems from the fact that it was easier to tell the
> buildbot to build a single port just once. The decision also probably is
> influenced by the fact that building more variants would use up more CPU
> resources on the buildbot servers, and would use up more disk space on the
> master packages server and all of its mirrors. I'm not saying that this
> extra burden is definitely too great; it might not be.
>
> If we wanted to build a single port more than once, we would have to tell
> the buildbot which combinations of variants to try to build, either as a
> hardcoded list or extracted from each port.
>
> Note that not all variants are either/or choices; many can be combined.
> This exponentially increases the number of builds that would need to be
> attempted, if we want to do all combinations of variants. If we consider a
> port with 1 variant, that's 2 (2^1) builds (1 with the variant, 1 without
> the variant). If a port has 2 variants, that's 4 (2^2) builds (with no
> variants; with one variant; with the other variant; with both variants). If
> a port has 3 variants, that's 8 (2^3) builds. If we take the webkit2-gtk
> port as an example, it has 6 variants. If none of its variants conflicted,
> that would be 64 (2^6) builds. Some of its variants do conflict though, so
> it would actually be fewer builds than that. Still, a single build of
> webkit2-gtk takes over an hour, so if we were to build all combinations of
> its variants, a single update of webkit2-gtk would tie up our build servers
> for days.
>
> Instead of building all combinations of variants, we could decide only to
> build specific predetermined variants. Here, you've requested +quartz;
> previously, +universal was requested. That would only be a maximum of 4
> builds per port, fewer if the port doesn't have one or both of those
> variants. That would be much more manageable.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20160508/ddb767ac/attachment.html>