qtN-kde port(s)

[René J.V. Bertin]

On Tuesday July 07 2015 21:50:44 Marko Käning wrote:

> > 
> > {{{
> > # preamble
> > 
> > if {[file exists ${prefix}/some/fingerprint/for/qt5-kde]} {
> >    PortGroup qt5-kde 1.0
> > } else {
> >    PortGroup qt5-mac 1.0
> > }
> > }}}
> 
> I have no idea what this fingerprint would actually be.

A specific file, either one installed anyway by Qt but in a location specific to qt5-kde, or something like a README or stub file that's specific to the port.

> Neither I know whether this would be a viable way to introduce two new port groups and put qt5 into pension.

PortGroup files can and do use PortGroup commands to include other port groups (ex: the qmake PortGroups). 

> 	Would be good to get some feedback on how to handle this.

The "problem" is how to define a Qt dependency that can be satisfied by qt5-mac or qt5-kde, each of which installs files in a different (and probably mutually exclusive) way. The (AFAIK accepted) way of doing that is with path dependencies in a PortGroup. I'm proposing to use at least a dedicated qt5-kde PortGroup that's interfaced through the general qt5 PortGroup because it allows to keep things more readable while also allowing dependent ports to express a default/preference. (An additional test would be required for that latter aspect, checking for the existence of either the fingerprint file or a variable.)

{{{
# preamble

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

then a port that wants qt5-kde as its default dependency could do

{{{
set qt5.prefer_kde yes
PortGroup qt5 1.0
}}}

I presume a nicer implementation with an option variable won't work here.

Anyway, yes, this could benefit from some discussion, because evidently one would have to duplicate at least the path: style dependency declarations in both the 2 actual payload PortGroups, or else move it into the generic/omnipotent PortGroup ...


> Right now I am struggling with phonon [1], since it doesn’t want to install itself with current qt5-mac on my system,
> but perhaps I better open a separate thread for that topic…

That's simply because the mainstream Qt5 PortGroup lost a variable my version defines and that indicates where the cmake modules are to be installed.
It's possible that there's no need to specify that location when all of Qt is dumped under a single prefix (try it!).
It's also possible that it isn't required when the cmake module dir is installed as it is under Linux; I (used to?) have a comment in my PortGroup pointing out that I'd kept the install location for those files unchanged only to limit the number of changes.

R.