On 10/10/16 2:18 PM, Ken Cunningham wrote: >> >> >> These are all legitimate and in my experience tend to come from trying to >> switch from building +x11 to building +quartz >> without "cleaning the slate" as it were. I always do this when switching >> like this (say with gimp2 that can build >> either way). >> >> sudo port install gimp2 (implied +x11 since it builds with x11 by default) >> sudo port deactivate active >> sudo port install gimp2 +quartz >> >> This ensures that all the various sub-dependencies get built in the correct >> flavor. >> >> Or install a separate MacPorts instance for building +quartz. I've >> successfully done this as well. >> >> I run into these issues alot with the GNOME ports because some GNOME ports >> can build +quartz but not all. In >> particular, ports that are part of the GNOME desktop infrastructure (e.g. >> gnome-desktop, gnome-settings-daemon) still >> use X11 features directly and thus can't be built +quartz. Others, like >> gcr, are just old implementations that use some >> X11 hack instead of porting to a backend agnostic gtk3 implementation. >> >> My general guidelines are this: if there is no +quartz variant, it builds >> with X11. This includes ports with no variant >> at all. Only ports with +quartz variants should be assumed to build that >> way. >> >> Dave >> > > Very helpful, thanks Dave. > > It’s true — I had decided to go with +quartz (why not, I thought) but then > something I wanted to install required +x11 along the way and I blew things > up when I tried to satisfy that dependency. > > I see there was a similar thread on the dev list that I noticed afterwards. > > Would there be use for a list or table of gtk ports that are only available > in either quartz or x11 variants, but not both, so someone might know going > in before they start which way to lean? Perhaps I might work on creating > something like that, for my own education if for no other reason.
Yes, that's a good idea. For some time, I've wanted to put together a database of GNOME ports with this information as well as various other attributes that can be used to easily generate an ongoing status web page. However, the issue overall isn't as simple as it seems at first blush. Issues for GTK2 ports are really not the same as for gtk3 ports and I can attest that the level of quartz backend support in GTK3/GNOME is not uniform over the range of ports but is really dependent on the interest level of a ports given developers. Overall quartz is taking a back seat to some other alternative backends, particularly wayland as a replacement for X11 on Linux platforms. Another issue is that of using variants themselves. variants are not tags but toggles. Giving a port a +x11 variant implies that -x11 makes sense and not necessarily in the Quartz sense. There are ports that optionally use/support X11 but can work without it altogether. It makes sense for them to have an +x11 variant. But, in my mind, a port that requires X11 and has no alternative to it should not have a +x11 variant. In ports like this I use require_active_variants liberally to let the user know if an +x11 variant is required in any key dependency. gnome-desktop and gcr are good examples of this. Finally, one of the big differences between gtk2 and gtk3 is that in gtk2 you have to build with one backend or the other. In gtk3, any and all backends can be built simultaneously (although we don't do it yet). So think about what the effect would be if you could build gtk3 +x11 +quartz in a manner similar to cairo and pango. In this mode, it would be up to the application to use the appropriate API (which exists in gtk3) to determine available backends and react appropriately in each case if it makes sense to do so. Some do now, some do not. Lots to think about but I'd welcome as a start a list that indicates which GNOME ports can be built +quartz, which could but are not yet appropriately ported or have been but don't work +quartz (yelp) and which, by their nature, cannot use Quartz without upstream modifications. Contact me off list if you (or anyone else for that matter) are interested in collaborating on such a list. Thanks, Dave _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
