[MacPorts] #49780: provide an interface for ports to depend on Qt5 components

23 Nov 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