#52742: buildbot: add support for building variants -----------------------------+--------------------- Reporter: mojca | Owner: admin@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: server/hosting | Version: Resolution: | Keywords: Port: buildbot | -----------------------------+--------------------- Comment (by mojca): The patches are pretty outdated, but they should give the first impression. I wanted to fix the second one, but I should probably write some code to parse options between `install-port` and `<portname>` first. Some hints by Clemens about how to proceed:
`tools/dependencies.tcl` just opens all ports without any specified variants. See `tools/dependencies.tcl` line 66; the last parameter to `mportopen`, which is currently `{}`, is the list of variants. The format is easy to create:
{{{ array set variations {} set variations(quartz) "+" set variations(x11) "-" mportopen ... [array get variations] }}}
gives you an mport reference as if the port was installed with `+quartz-x11`. You should be able to find some suitable parsing code for variants given on the command line in `src/port/port.tcl`, line 1695 and following.
Looking at that file I have an impression that we forgot to consider global settings (`[array get global_variations]`):
{{{ if {!$index_only} { # Add any global_variations to the variations # specified for the port (so we get e.g. dependencies right) array unset merged_variations array set merged_variations [array get variations] foreach { variation value } [array get global_variations] { if { ![info exists merged_variations($variation)] } { set merged_variations($variation) $value } } }}}
This means that even if someone would (theoretically) set up a buildbot with `+quartz -x11` in configuration file, those setting would probably be ignored. Or do I misunderstand the concept?
Yes, I think the file doesn't handle global variants. I think it's also bad design that `port/port.tcl` has to do the merging of variant specs without at least some library support from `macports1.0`, but that's a story for a different refactoring.
An additional warning:
However, this output will only list positive variants, it will not list default variants that have been explicitly disabled. This might be a problem, because specifying `-x11 +quartz` will just give you a list of all dependencies with `+quartz`, but not without `+x11`, so if a port is written in a way that it does not automatically disable `x11` if `+quartz` is given (for example if both are supported simultaneously and `x11` is the default), this might lead to unexpected results. I haven't tested any of this, but we probably should.
-- Ticket URL: <https://trac.macports.org/ticket/52742#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X