[MacPorts] #49780: provide an interface for ports to depend on Qt5 components
MacPorts
noreply at macports.org
Mon Nov 23 06:54:21 PST 2015
#49780: provide an interface for ports to depend on Qt5 components
-------------------------+--------------------------------
Reporter: rjvbertin@… | Owner: macports-tickets@…
Type: enhancement | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Keywords: | Port: qt5/qt5-kde
-------------------------+--------------------------------
`port:qt5` has been modified to allow the installation of individual Qt
components, so that ports requiring only a subset need not install all of
Qt5, if they so desire.
I have decided not to follow this beyond the subports my own proposed
`port:qt5-kde` already provides. Its Portfile is complex enough as it is
because it also provides Qt 5.3.2 on OS X 10.6, and I am rather convinced
that installing all or part of KF5 will require about all that
`port:qt5-kde` currently provides anyway.
It is my desire however that users who install `port:qt5-kde` can still
install any other port depending on Qt5, even if that calls for specific
Qt5 components.
Until now, including the PortGroup was enough to add a dependency on the
corresponding Qt port, and that dependency was "path-style" so that one
could have either QtN-mac or QtN-mac-devel installed.
I think that we need to come up with an interface to define dependencies
on, say qt5-qtbase, qt5-svg and qt5-qttools (random selection) such that
those dependencies will be satisfied at least by either `port:qt5` or
`port:qt5-kde`.
That could be done by defining variables in the PortGroup (read: in the
mainstream PortGroup as well as in my qt5-kde PortGroup), which dependent
ports can then use in their `depends_lib` statement.
I have given this question some thought for the KF5 Frameworks port I am
working on, which is also a (huge) metaport providing individual
frameworks in individual subports. I have foreseen from scratch the
possibility that sooner or later I would be testing "-devel" versions of
certain of those (sub)ports, so I came up with this:
{{{
# variables to facilitate setting up dependencies to KF5 frameworks that
may (or not)
# also exist as port:kf5-foo-devel .
proc kf5.framework_dependency {name {library 0}} {
upvar #0 kf5.${name}_dep dep
if {${library} ne 0} {
set kf5.lib_path lib
set kf5.lib_ext 5.dylib
set dep
path:${kf5.lib_path}/${library}.${kf5.lib_ext}:kf5-${name}
ui_debug "Dependency expression for KF5ramework ${name}: ${dep}"
} else {
if {[info exists dep]} {
return ${dep}
} else {
set allknown [info global "kf5.*_dep"]
ui_error "No KF5 framework is known corresponding to
\"${name}\""
ui_msg "Known framework ports: ${allknown}"
return -code error "Unknown KF5 framework ${name}"
}
}
}
# kf5.depends_frameworks appends the ports corresponding to the KF5
Frameworks
# short names to depends_lib
proc kf5.depends_frameworks {first args} {
depends_lib-append [kf5.framework_dependency ${first}]
foreach f ${args} {
depends_lib-append \
[kf5.framework_dependency ${f}]
}
}
proc kf5.depends_build_frameworks {first args} {
depends_build-append \
[kf5.framework_dependency ${first}]
foreach f ${args} {
depends_build-append \
[kf5.framework_dependency ${f}]
}
}
kf5.framework_dependency attica libKF5Attica
}}}
That last line declares the library that has to be present if
`port:kf5-attica` is installed (or any other port replacing it). As an
example, the `kf5-kwallet` subport now declares the frameworks it requires
like this:
{{{
kf5.depends_frameworks \
gpgmepp kconfig kcoreaddons kdbusaddons ki18n \
kiconthemes knotifications kservice kwidgetsaddons \
kwindowsystem
}}}
A similar mechanism could be implemented through the Qt5 PortGroup
(however we organise that one) that allows ports to declare dependencies
on Qt5 components that translate into
`${qt_frameworks_dir}/QtCore.framework/QtCore:qt5-qtbase`,
`${qt_frameworks_dir}/QtSvg.framework/QtSvg:qt5-qtsvg` etc.
Thoughts?
--
Ticket URL: <https://trac.macports.org/ticket/49780>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list