subport and keyword questions/suggestions

[René J.V. Bertin]

Hi,

I'm still polishing my proposed changes to the Qt ports, and am beginning to wonder if I shouldn't replace the +KDE variant by a qt5-mac[-devel]-KDE subport. At this point the +KDE variant isn't required, but it does have a patch or 2 that are "strongly suggested" to improve the KDE4 experience, and we don't know yet to what extent KF5 will impose patches that users of only "pure Qt5" applications might wish to avoid.
Whatever happens, it's rather certain that KF5 users will want to avoid building a non-default variant from source: Qt 5.4 takes more than just a few hours to build and while a faster machine than my 2*2 2.7Ghz i7 will do that quicker, it will still need the around 27Gb (!) for the source and build directories.

So, question 1:

- Do the build slaves build the default variants of subports?

I *think* that the mechanism that's currently in place to let client ports accept qt5-mac-devel instead of qt5-mac should also let them accept qt5-mac[-devel]-kde instead of qt5-mac, but that remains to be confirmed. In any case it only works because Qt ports are more or less obliged to use the corresponding PortGroup. A more reliable and universal approach would be this:

- Has a complementary feature (as in complementary colours) to the replaced_by keyword ever been considered? A keyword that allows a port to indicate that it's an alternative to another port? I'm not sure how invasive the addition of such a keyword would be, nor how easy to implement for someone who doesn't know MacPorts inner works (like me). Is this something to request on trac?

@kde-mac: what do you think, should I prepare a qt5-mac-kde subport? I'd prefer to lay the foundations for that now if we think that there's enough chance it'll become necessary, rather than have to come back to my Portfile code at a future time (and potentially disrupt a lot more Qt5 client ports than I currently have).

R.