id summary reporter owner description type status priority milestone component version resolution keywords cc port 48967 submission: port:qt5-kde RJVB "Marko Käning and I discussed the benefits of having a dedicated Qt5 ports on which future KF5 ports could depend in the past, and the idea became much more appealing just before summer after mcalhoun updated his long-neglected port:qt5-mac discarding my own months of work on this port almost completely. In short, this proposed port:qt5-kde : - currently provides Qt 5.5.0 - is coinstallable with Qt4 (but not other Qt5 port(s) of course) - incorporates a set of patches based on those for Qt4 that improve the user experience with KF5 apps (formerly provided as the +KDE variant) - uses the install layout based on the tried-and-true layout of the non-coinstallable port:qt4-mac; version-specific executables and libraries/frameworks are installed under ${prefix}/libexec/qt5, headerfiles under ${prefix}/include/qt5 and the rest under ${prefix}/share/qt5 and ${prefix}/share/doc/qt5 (which is how port:qt4-mac installed these items). I am convinced that this layout to be preferred when using Qt-based applications that adhere to Freedesktop conventions and are supposed to be able to interact and share resources with other Freedesktop applications (GTk/Gnome). - includes a patch that will allow (KF5) applications to find shared resources in the standard XDG-style locations (${prefix}/share, etc) rather than in OS X style locations (~/Library/Application Support, etc). This patch needs to be activated so doesn't affect (pure Qt) applications that were built without the activator. - provides a legacy variant that builds Qt 5.3.2; this is automatic on OS X 10.6 where that Qt version is the latest that can be built (requires port:clang-3.4 or port:clang-3.5). I believe the above feature set justifies having an additional, alternative Qt5 port. In order for dependent ports to function with both ports, I split up the Qt5 Portgroup in a qt5-mac and a qt5-kde Portgroup; the new Qt5 Portgroup contains a selection mechanism to force select either the one or the other but will also load the appropriate Portgroup as a function of whether port:qt5-mac or port:qt5-kde is installed. The default/fallback is to install port:qt5-mac ; the changes to the Qt5 Portgroup should be transparent (and are indeed according to my testing). Binary builds against port:qt5-mac will of course not function with port:qt5-kde. Therefore, the qt5-kde Portgroup defines a (default) variant (qt5kde) that should only be known to the build bots for ports that require port:qt5-kde specifically. A user having port:qt5-kde installed and requesting the install/upgrade of a generic Qt5 port (say, port:qt5-creator) will in fact request port:qt5-creator+qt5kde, which is not available in binary version. This mechanism is of course not tested exhaustively, and I am open to ways to improve it. As a bonus feature, this port also builds on Linux. ;) I'm uploading a tarchive that contains everything needed; uploading diffs wouldn't make a lot of sense (they wouldn't be easier to peruse than studying the Portfile, patches and portgroup files, IMHO). The evolution of this port can also be followed on my repo, github.com/RJVB/macstrop ." submission assigned Normal ports mojca qt5-kde