> On Mar 4, 2017, at 08:10, Craig Treleaven <[email protected]> wrote: > >> On Mar 3, 2017, at 10:26 PM, Mojca Miklavec <[email protected]> wrote: >> >> On 4 March 2017 at 03:51, Craig Treleaven wrote: >>> I know that we would like to find a clean solution to building ports with >>> non-default variants. As an interim step, however, I wonder if we might >>> consider a buildbot that is configured to default to “+quartz”? >> >> We don't even need a separate buildbot. Just a relatively simple >> improvement to the existing buildbot. >> >> See: >> https://trac.macports.org/ticket/52742 >> >> I suggested adding a field to allow manually specifying arbitrary >> values for variants. But we would need some automatism as well. >> Perhaps something like the following: >> >> If variant quartz exists, build the port once again, but this time >> with '+quartz' >> >> but covering all corner cases (when +x11 +quartz is allowed together >> and when it is not …). > > If we use the existing buildbot instances, won’t they they try to upload > built binaries to packages.macports.org?
Of course. Isn't that what you're asking for? If not, why not? > In another ticket [1], you noted the problem where an indirect dependency > must be built with +quartz. If a port is installed with a variant, MacPorts already correctly handles installing inactive dependencies with that same variant if they have that variant; it has for many years. (It doesn't reinstall active dependencies with that variant, but this won't be a problem on the buildbot because all ports are deactivated between builds.) There could of course be a problem with ports that don't have a quartz variant that nevertheless build themselves differently depending on whether their dependencies are using a quartz variant or not. When we discover such problems, we should fix them by adding a quartz variant to such ports. And this problem exists whether or not we're building binary packages. > This is why I felt a dedicated “PlusQuartz” buildbot might be a simple > solution that we could get running quickly. > > [1] https://trac.macports.org/ticket/40294 > > I note that there have been tickets about this practically since the > buildbots were first implemented. I think it would be better to get a partial > solution implemented now rather than spend more years waiting for perfection. > As they say: “Late answers are wrong answers." As I recall, mpbb and our buildbot config are ready for building non-default variants. We just need to make a few further changes to tell portwatcher to schedule additional portbuilder builds with different variants, depending on certain criteria. We need to decide what those criteria are, then write the code to do that. For example, a criterion could be "if a port has a quartz variant, schedule another build with the quartz variant". Another useful criterion to help keep binaries of wine's dependencies up to date would be "if a port has a universal variant and a universal version of the port is currently installed on the buildbot, schedule another build with the universal variant". On the other hand, nothing has been implemented for your separate quartz buildbot idea. You idea sounds like it would use a lot more (twice as many) server resources and be a lot more work to set up. I don't see any reason to go that route. > Craig > (Second attempt to send; using lists.macports.org didn’t work.) What was the problem?
