id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,port 53778,Qt5/qt5-kde PortGroup,RJVB,,"We should be picking up this affair, and I think the proper way to proceed is to tackle the PortGroup question first, and the main goal of this ticket is to apply suitable changes to the PortGroup files for the current port:qt5 port family. That means adding a hopefully simple section (to qt5-1.0.tcl and qmake5-1.0.tcl) that will take care of *transferring* control to the appropriate PortGroup (qt5-kde-1.0.tcl or qmake5-kde-1.0.tcl respectively). That section will probably also contain a bit of ""glue"" because of variables or procedure missing (or gone missing) from qt5-1.0.tcl . One important note and big request: addres https://trac.macports.org/ticket/53777 I am still working on the qt5-kde-1.0 vs. qt5-1.0 inclusion logic so for now I only attach the qmake5*-1.0 PortGroups which are in a state that should work with the existing other PortGroup files. The change to qmake-1.0.tcl assumes that the `PortGroup qt5 1.0` statement will include the proper Qt5 PortGroup, and transfers control to qmake5-kde-1.0.tcl if port:qt5-kde is being used (is installed). This is detected by checking `qt5.using_kde` (following that variable's intended use). KDE software rarely if ever uses QMake, so there is no justification for software that does to impose the use of port:qt5-kde so the qmake5-kde PortGroup cannot be included directly. There are some KDE dependencies that use QMake however; ports for those could do this to indicate their preference for port:qt5-kde : {{{ set qt5.prefer_kde yes PortGroup qmake5 1.0 }}}",submission,new,Normal,,ports,,,"haspatch, portgroup",MarcusCalhoun-Lopez mkae mojca,qt5