[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