provide an interface for ports to depend on Qt5 components

[RJVB (René Bertin)]

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?

[RJVB (René Bertin)]

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-")? :)

[ctreleaven (Craig Treleaven)]

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?

[RJVB (René Bertin)]

Replying to 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.

[mkae (Marko Käning)]

Cc Me!

[mkae (Marko Käning)]

What exactly is the status of this? I guess it's all part of qt5-kde(-devel) these days, no!?

[RJVB (René Bertin)]

Yes, and see #51619 .