"concurrent" qt4-mac: request feedback & testing for current port phase in Portfile?
"René J.V. Bertin"
rjvbertin at gmail.com
Tue Dec 9 13:54:19 PST 2014
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é
More information about the macports-users
mailing list