[KDE/Mac] "concurrent" qt4-mac: request feedback & testing for current port phase in Portfile?

["René J.V. Bertin"]

Hello,

I've taken my courage with 3 hands, and started working on a +concurrent variant for qt4-mac, as a prerogative to having a ditto variant for qt5-mac (which won't even build when qt4-mac is installed).

Still with me?

So rather than using a new port, I went with a variant that is actually defined in the PortGroup file so that dependent ports inherit it. The modified paths are also defined in the PortGroup file, qt4-1.0.tcl, but the actual logic is left to the qt4-mac Portfile. (Which I split, but that's a different topic.)

In qt4-1.0.tcl I now have:

if {[variant_isset concurrent]} {
    # we're asking for a concurrent install. No need to guess anything, give the user what s/he wants
    set is_concurrent   1
} else {
    # check if Qt4 was installed with +concurrent, unless we're (re)building without that variant
    # that means that either building_qt4 isn't set, or the port's ${name} != "qt4-mac"
    # or the name variable isn't defined yet. That means the qt4-mac portfile must define its name
    # before declaring itself a member of PortGroup qt4!!
    if {![info exists building_qt4] || ![info exists name] || ${name} ne "qt4-mac"} {
        if {[file exists ${prefix}/libexec/${qt_name}/bin/qmake]} {
            # we have a "concurrent" install, which means we must look for the various components
            # in different locations (esp. qmake)
            set is_concurrent   1
            set auto_concurrent 1
            ui_msg "NB:\nQt4 has been installed with +concurrent, dependent ports\nwill inherit that variant implicitly\n"
            default_variants +concurrent
        }
    }
}

What this does is that it detects if qt4-mac has been installed with +concurrent (in similar fashion as the +debug variant is detected, i.e. from what's present on disk, not from the registry). If the variant is detected, it is set as a default variant. This is actually not required, as event without that the variant is inherited implicitly, through the dependencies on Qt4.

2 questions:
- is this a good approach? Semantically speaking one could argue that dependent ports don't get the choice, so it's a bit of a misnomer ... but if you want to be able to have either the standard or the concurrent qt4-mac variant activated (which one cannot prohibit), dependent ports should be able to "follow" this.
- the mechanism mostly works, except ... for activating a non-concurrent variant. Is it possible to know the phase being activated (= the action demanded by the user) so that default_variants can be skipped when required (for activate, deactivate and uninstall, possibly others)? Or am I overlooking another way to set the default variant only when required?

Additional questions:
- what other obstacles might I run into and/or what should I test and double-check?
- I added a +libsymlinks variant that provides "backwards compatibility" for existing, installed ports by symlinking shared libraries and the like into their usual ("-concurrent") locations in post-destroot. Suggestions for a better name?

Thanks,
René