[MacPorts] #49780: provide an interface for ports to depend on Qt5 components
#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
#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: Resolution: | Keywords: Port: qt5/qt5-kde | --------------------------+-------------------------------- Comment (by rjvbertin@…): BTW, need I point out how much more readable the `kf5.depends_frameworks` expression above is than a list of path-style dependencies or even a list of regular `port:` dependencies that each repeat the same suffix ("kf5-" or "qt5-")? :) -- Ticket URL: <https://trac.macports.org/ticket/49780#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#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: Resolution: | Keywords: Port: qt5/qt5-kde | --------------------------+-------------------------------- Comment (by ctreleaven@…): Can we back up a bit? I'm only familiar with Qt to the extent that the main port I support (mythtv) relies on Qt. What are these "individual Qt components" that you wish to make optional? Do you have a list? What is the motivation for NOT including them? I think there are two considerations that point toward including all non-conflicting components in a default installation of Qt: 1) MacPorts philosophy has generally been to include all reasonable components unless such inclusion massively inflates the resulting port with software that is not required by most users. Is that the case with Qt5? How much bigger is the pre-compiled archive for the mostly-inclusive package v. the base package you've proposed. 2) How is the Qt project packaging Qt5? For Qt4, the download from their site was pretty much all-encompassing. If Qt5 is the same, what is the compelling reason for MacPorts to Qt5 in bits and pieces? -- Ticket URL: <https://trac.macports.org/ticket/49780#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
#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: Resolution: | Keywords: Port: qt5/qt5-kde | --------------------------+-------------------------------- Comment (by rjvbertin@…): Replying to [comment:2 ctreleaven@…]:
Can we back up a bit?
If only we could ...
I'm only familiar with Qt to the extent that the main port I support (mythtv) relies on Qt. What are these "individual Qt components" that you wish to make optional? Do you have a list?
See https://www.macports.org/ports.php?by=name&substr=qt5 (or https://trac.macports.org/browser/trunk/dports/aqua/qt5/Portfile, but that one throws an error for me). Note that *I* do not wish to split up Qt5 like that. It's the more-or-less suggested way of installing Qt advocates themselves, though evidently their toplevel build system still builds and installs everything if you let it. Read my post: I have decided against splitting up my own port. It only provides a few subports correspond that are not examples or docs: - QtWebengine : new and about as expensive to build as the rest of Qt5 - the X11/Xcb platform plugin - some database plugins (only 1 of which is actually provided through the main port, and I rolled the sqlite3 plugin back into the main port).
What is the motivation for NOT including them?
Qt's motivation probably reads like this: Linux distributions were already splitting things up so users don't need to install more than they need, and they have a point so we'll make it easier for them.
I think there are two considerations that point toward including all non- conflicting components in a default installation of Qt:
1) MacPorts philosophy has generally been to include all reasonable components unless such inclusion massively inflates the resulting port with software that is not required by most users. Is that the case with Qt5? How much bigger is the pre-compiled archive for the mostly-inclusive package v. the base package you've proposed.
I agree, and that's what led to my decision to do things as outlined above. As a result, my qt5-kde port installs all components qt4-mac did and does, plus a few newer, small components that aren't expensive to build. You'd have to ask mcalhoun for the numbers. I don't really intend to install the mainstream Qt5 port as long as I can get away with it. I've been running my own Qt5 port since I made it co-installable with the Qt4 one (which I gave that treatment first), meaning since Feb. or March of this year. As a result I probably have more Qt5 dependents than most other MacPorts users, and since neither of the 2 maintainers of the mainstream Qt ports was willing at least to consider my install layout *), it is (probably) not trivial to swap mine and their ports for testing.
2) How is the Qt project packaging Qt5? For Qt4, the download from their site was pretty much all-encompassing. If Qt5 is the same, what is the compelling reason for MacPorts to Qt5 in bits and pieces?
The download is still a single monolithic tarball. *) Layout: I realised very early in the process of making the ports co- installable that only minimal changes were required to make that happen. Basically, everything that was installed under ${prefix}/share was already in qt4 and qt5 directories respectively, so could remain in place. Both michaelld and mcalhoun decided to move everything into an all-encompassing prefix under libexec, despite the extra work and risk for breakage that represented. -- Ticket URL: <https://trac.macports.org/ticket/49780#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#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: Resolution: | Keywords: Port: qt5 qt5-kde | --------------------------+-------------------------------- Changes (by mf2k@…): * port: qt5/qt5-kde => qt5 qt5-kde -- Ticket URL: <https://trac.macports.org/ticket/49780#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts