Building GTK-dependents +quartz vs. +x11

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Building GTK-dependents +quartz vs. +x11

David Richmond
I saw some old discussion on the user list (https://lists.macports.org/pipermail/macports-users/2016-October/042063.html) about some challenges of +quartz / +x11 builds and conflicts with GTK. So I don't think (?) the following behavior is a bug.

I was working on documentation (and will ultimately write a Portfile when I can learn how) for others to build Denemo, a program with dependencies on aubio and gtk3, among others; I suggested building gtk3 +quartz. A user with no macports installed followed my instructions and had gtk +quartz fail with the error that gdk-pixbuf2 had been built with x11.

Well, it's because the first package he built, aubio, has the dependencies: aubio => ffmpeg => librsvg => cairo => gdk-pixbuf2. librsvg has +x11 and +quartz variants, but aubio and ffmpeg do not, so they end up calling in x11 by default. I had aubio as the first package to build. So the solution (without a Portfile) is to build all the +quartz ports first, and then aubio and ffmpeg do not try to build x11 stuff since the relevant packages were already built.

Since, I presume, a Portfile will let MacPorts sort out the order of installation for the user, I suppose that the "right" way to write a new Portfile is just to tell Macports about your build's immediate dependencies in either variant +x11 or +quartz, and if then it errors out, it's the user's problem to sort out the error messages in case they have both x11 and quartz going in parallel by user accident. Does that seem right?

Thanks for walking a novice through some of these issues.

David
Reply | Threaded
Open this post in threaded view
|

Re: Building GTK-dependents +quartz vs. +x11

ryandesign2
Administrator


On Jul 3, 2020, at 06:45, David Richmond wrote:

> I saw some old discussion on the user list (https://lists.macports.org/pipermail/macports-users/2016-October/042063.html) about some challenges of +quartz / +x11 builds and conflicts with GTK. So I don't think (?) the following behavior is a bug.
>
> I was working on documentation (and will ultimately write a Portfile when I can learn how) for others to build Denemo, a program with dependencies on aubio and gtk3, among others; I suggested building gtk3 +quartz. A user with no macports installed followed my instructions and had gtk +quartz fail with the error that gdk-pixbuf2 had been built with x11.
>
> Well, it's because the first package he built, aubio, has the dependencies: aubio => ffmpeg => librsvg => cairo => gdk-pixbuf2. librsvg has +x11 and +quartz variants, but aubio and ffmpeg do not, so they end up calling in x11 by default. I had aubio as the first package to build. So the solution (without a Portfile) is to build all the +quartz ports first, and then aubio and ffmpeg do not try to build x11 stuff since the relevant packages were already built.
>
> Since, I presume, a Portfile will let MacPorts sort out the order of installation for the user, I suppose that the "right" way to write a new Portfile is just to tell Macports about your build's immediate dependencies in either variant +x11 or +quartz, and if then it errors out, it's the user's problem to sort out the error messages in case they have both x11 and quartz going in parallel by user accident. Does that seem right?
>
> Thanks for walking a novice through some of these issues.

The choice of whether to use +x11 or +quartz should be made for the entire MacPorts installation, because so many ports are related to or dependent upon one another. If the user changes their mind about which of those variants to use, they should uninstall all ports, then make the change in variants.conf, then reinstall ports.

It would be nice if we would redesign this so that the x11 and quartz flavors could be installed side-by-side using subports. But we have not even begun to consider how such a transition could be implemented.

https://trac.macports.org/ticket/60511