qtN-kde port(s)

[René J.V. Bertin]

Hi Marko,

I've been thinking a bit more about our idea of setting up KDE/KF5 specific Qt port(s) with patches aimed at improving the KDE experience and an install layout that mimics the one used on Linux as much as possible (i.e. my time-tested concurrent install layout).

I'd be interested in doing that, but if and only if it can be done in such a way that the choice to install qt{4,5}-kde rather than the "mac" alternative is strictly up to the user the same way as it's possible to use a -devel port.

I think that can only be done by modifying the Qt PortGroup files so that they detect the install layout and adapt the variable definitions they serve accordingly. The cleanest approach I can think of (taking Qt5 as an example) would rename qt5-1.0.tcl to qt5-mac-1.0.tcl and then rewrite qt5-1.0.tcl as follows:

{{{
# preamble

if {[file exists ${prefix}/some/fingerprint/for/qt5-kde]} {
    PortGroup qt5-kde 1.0
} else {
    PortGroup qt5-mac 1.0
}
}}}

Alternatively, one could leave the current mainstream qt5-1.0.tcl payload inside that else{} block instead of moving it to an individual file, but IMHO that just increases the risk someone careless breaks qt5-kde functionality .
The qt5-kde Portfile would then have to depend on the qt5-kde PortGroup, but all other ports should be able to continue to use the qt5 PortGroup; if done correctly there's no reason anyone would notice before a modification to the PortGroup becomes necessary because of other reasons.

The crucial question is of course if you could push such a change to the PortGroup file(s) without all hell breaking loose. 

I would propose to do this before upgrading Qt to 5.5.0 (which is something I don't think has any urgency at all).

I don't think there's any point in allowing side-by-side installation of qtN-mac and qtN-kde, but I'm not against discussing that point.

Cheers,
René