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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
