Hi, I'm experimenting with an idea for my Linux adaptation of MacPorts "base" and apparently need some insights on the internal implementation. No risk for this to taint the Mac version!
The idea is to add a global variant like +universal, ultimately via portutil.tcl but for the time being in a PortGroup. This variant would conflict with any variant individual ports might declare, so I was hoping to modify those variants in a callback. Conflicts are stored in $PortInfo(vinfo)($currentVariant)(conflicts) (assuming that's the correct way to address an element of an array that's an element of an array itself also stored in a toplevel array), and I managed to modify it in a way that shows up via `port variants`: {{{ platform linux { variant testIdea description {Some fancy new experiment.} {} set newVariantName testIdea } proc LTO::callback {} { # this callback could really also handle the disable and allow switches! global supported_archs LTO.must_be_disabled global PortInfo newVariantName platform linux { if {[variant_exists ${newVariantName}] && [info exist PortInfo(variants)] && [info exists PortInfo(vinfo)]} { array unset vinfo array set vinfo $PortInfo(vinfo) foreach v $PortInfo(variants) { array unset variant array set variant $vinfo(${v}) if {[info exists variant(conflicts)]} { ui_debug "${v}: conflicts with $variant(conflicts), adding +${newVariantName}" set conflicts [join [lsort "$variant(conflicts) ${newVariantName}"]] } else { ui_debug "${v}: adding conflict with +${newVariantName}" set conflicts "${newVariantName}" } array set variant [list conflicts ${conflicts}] array set vinfo [list ${v} [array get variant]] array set PortInfo [list vinfo [array get vinfo]] } } } #snip }}} {{{ > port -v variants openssl openssl has the variants: LTO: build with link-time optimisation * conflicts with testIdea builtwith: Label the install with the compiler used * conflicts with testIdea cpucompat: Build using some commonly supported SIMD settings for optimal cross-CPU tuning * conflicts with cputuned testIdea cputuned: Build using -march=native for optimal tuning to your CPU * conflicts with cpucompat testIdea docs: install (html) documentation * conflicts with testIdea testIdea: Some fancy new experiment. * conflicts with testIdea use_lld: use the LLD linker * conflicts with testIdea }}} However, while this doesn't break existing conflict situations it does not actually add a functional new conflict: {{{ > port -v variants openssl +cputuned+cpucompat Error: openssl: Variant cputuned conflicts with cpucompat Error: Unable to open port: Error evaluating variants }}} {{{ > port -v variants openssl +cputuned+testIdea openssl has the variants: LTO: build with link-time optimisation * conflicts with testIdea builtwith: Label the install with the compiler used * conflicts with testIdea cpucompat: Build using some commonly supported SIMD settings for optimal cross-CPU tuning * conflicts with cputuned testIdea +cputuned: Build using -march=native for optimal tuning to your CPU * conflicts with cpucompat testIdea docs: install (html) documentation * conflicts with testIdea +testIdea: Some fancy new experiment. * conflicts with testIdea use_lld: use the LLD linker * conflicts with testIdea }}} My initial idea was that `PortInfo` might be a copy so modifying it would be pointless, but that seems unlikely since the modifications show up via `port variants`. Am I overlooking something, or should I simply do the conflict detection myself? I realise that might be needed anyway since IIRC the `default_variants` feature also doesn't play nice with declared variant conflicts. Thanks in advance, R.