Modifying the PortInfo data from a PortGroup?

[René J.V. Bertin]

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.