[MacPorts] #48967: submission: port:qt5-kde

MacPorts noreply at macports.org
Thu Sep 24 10:27:27 PDT 2015


#48967: submission: port:qt5-kde
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  submission   |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:  2.3.3
 Keywords:               |       Port:  qt5-kde
-------------------------+--------------------------------
 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 .

-- 
Ticket URL: <https://trac.macports.org/ticket/48967>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list