Qt5/qt5-kde PortGroup

[RJVB (René Bertin)]

We should be picking up this affair, and I think the proper way to proceed is to tackle the PortGroup question first, and the main goal of this ticket is to apply suitable changes to the PortGroup files for the current port:qt5 port family.

That means adding a hopefully simple section (to qt5-1.0.tcl and qmake5-1.0.tcl) that will take care of *transferring* control to the appropriate PortGroup (qt5-kde-1.0.tcl or qmake5-kde-1.0.tcl respectively). That section will probably also contain a bit of "glue" because of variables or procedure missing (or gone missing) from qt5-1.0.tcl .

One important note and big request: addres ​https://trac.macports.org/ticket/53777

I am still working on the qt5-kde-1.0 vs. qt5-1.0 inclusion logic so for now I only attach the qmake5*-1.0 PortGroups which are in a state that should work with the existing other PortGroup files. The change to qmake-1.0.tcl assumes that the PortGroup qt5 1.0 statement will include the proper Qt5 PortGroup, and transfers control to qmake5-kde-1.0.tcl if port:qt5-kde is being used (is installed). This is detected by checking qt5.using_kde (following that variable's intended use).

KDE software rarely if ever uses QMake, so there is no justification for software that does to impose the use of port:qt5-kde so the qmake5-kde PortGroup cannot be included directly. There are some KDE dependencies that use QMake however; ports for those could do this to indicate their preference for port:qt5-kde :

set qt5.prefer_kde            yes
PortGroup                     qmake5 1.0

[RJVB (René Bertin)]

for reference, the qmake5-kde-1.0.tcl version

[RJVB (René Bertin)]

FWIW, I thought I had made this an "enhancement" ticket, but "submission" is probably appropriate too.

[RJVB (René Bertin)]

patch for qt5-1.0.tcl

[RJVB (René Bertin)]

I have now a working prototype for the changes I would make to the qt5 1.0 PG. In order:

1. Move the qt5.using_kde declaration downwards, until *after* the potential control transfer to qt5-kde-1.0.tcl . This means the qt5-kde PG can continue to assume qt5.using_kde is never defined when it is loaded for the 1st time (and also means it can continue to use a standard Tcl variable). I realise it means that the variable won't be set when just_want_qt5_version_info is true, but I think there is little need for that anyway (correct me if I'm wrong).
2. the control transfer logic itself, with what I hope are sufficient comments to explain what it does and why. In particular I think it's easier to distinguish between active port:qt5-qtbase and port:qt5-kde variants from installed files rather than from the registry for 2 reasons:
   1. there are now 3 qt5-qtbase ports ({qt5,qt55,qt56}-qtbase) with possibly more to come
   2. qt5-kde may also have a matching qt56-kde port, and also has a qt5-kde-devel variant that may be committed as well as another devel variant that will remain private to KF5 port maintainers and testers.

All those different Qt5 ports install the same files, with certain differences between qt5*-qtbase and qt5*-kde* that are independent of Qt version; the depspecs provided by qt5.depends_component are based on this fact too.

(And as argued a while back on the ML: a single check for the existence of a given file *must* require less operations than doing a pattern-match on the result of a registry lookup, and is thus almost certainly faster at least in theory.)

You may notice the references to OS X 10.6 . Port:qt5-kde contains the rather blackish magic I concocted quite a while ago now to build Qt 5.3.2 on that legacy OS version. It worked fine (even a universal build, IIRC) but I haven't tested it in a long time. In itself this support has nothing to do with KDE (much of KF5 now requires more recent Qt versions anyway) so I'm open to discussion about separating it, for instance in favour of a port:qt53 .

[RJVB (René Bertin)]

Here's the equivalent block from my own qt5-kde-1.0.tcl PG, transferring control to qt5-1.0.tcl in the opposite cases and when just_want_qt5_version_info is true.

I've paid a bit less attention to comments and layout here.

if {[tbool just_want_qt5_version_info]} {
    PortGroup           qt5 1.0
    return
}

# Check what Qt5 installation flavour already exists, or if not if the port calling us
# indicated a preference. If not, use the default/mainstream port:qt5 .
# Also use qt5-kde if we're on 10.6 because qt5-kde provides a fallback to Qt 5.3.2 on that OS version

# first, check if port:qt5-kde or a port:qt5-kde-devel is installed, or if we're on Mac OS X 10.6
# NB: the qt5-kde-devel ports may never exist officially in MacPorts but is used locally by KF5 port maintainers!
if {[file exists ${prefix}/include/qt5/QtCore/QtCore] || ${os.major} == 10} {
    # Qt5 has been installed through port:qt5-kde or port:qt5-kde-devel
    ui_debug "Qt5 is provided by port:qt5-kde"
    # we're in the right PortGroup, otherwise we'd need to
    # PortGroup           qt5-kde 1.0
    set qt5.using_kde   yes
} elseif {[file exists ${prefix}/libexec/qt5/plugins]
        && [file type ${prefix}/libexec/qt5/plugins] eq "directory"} {
    # qt5-qtbase is installed: Qt5 has been installed through a standard port:qt5 port
    # (checking if "plugins" is a directory is probably redundant)
    ui_debug "Qt5 is provided by port:qt5"
    PortGroup           qt5 1.0
    if {[info exists qt5.prefer_kde] && [info exists building_qt5]} {
        # user tries to install say qt5-kde-qtwebkit against qt5-qtbase etc.
        ui_error "You cannot install a Qt5-KDE port with port:qt5 or one of its subports installed!"
        # print the error but only raise it when attempting to fetch or configure the port.
        pre-fetch {
            return -code error "Deactivate the conflicting port:qt5 port(s) first!"
        }
        pre-configure {
            return -code error "Deactivate the conflicting port:qt5 port(s) first!"
        }
    }
    # we're done
    return
} elseif {[info exists qt5.prefer_kde]} {
    # The calling port has indicated a preference and no Qt5 port is installed already
    ui_debug "Qt5 will be provided by port:qt5-kde, by request"
    # we're in the right PortGroup, otherwise we'd need to
    # PortGroup           qt5-kde 1.0
    set qt5.using_kde   yes
} else {
    # default fall-back to mainstream port:qt5
    ui_debug "Qt5 will be provided by port:qt5 (default)"
    PortGroup           qt5 1.0
    # we're done
    return
}

# # this shouldn't be necessary (already done by qt5-1.0.tcl and impossible here if we return immediately after loading that file):
# if {![tbool qt5.using_kde]} {
#     # we're back from `PortGroup qt5 1.0`, add some finishing touches and then return
#     if {[info exists qt5.prefer_kde]} {
#         # this is a port that prefers port:qt5-kde and thus expects most of Qt5 to be installed
#         # through that single port rather than enumerate all components it depends on.
#         depends_lib-append  port:qt5
#     }
#     if {![info exists qt_cmake_defines]} {
#         # the Qt5 PortGroups used to define a variable that is no longer provided by qt5-mac-1.0.tcl;
#         # set it to an empty value so that it can be referenced without side-effects.
#         global qt_cmake_defines
#         set qt_cmake_defines ""
#     }
#     # we're done now.
#     return
# }

######### checks that should never trigger (and raise errors) #########

[RJVB (René Bertin)]

updated qt5-1.0 PG patch (for rev. 9e44fe58a605e66730f8f50353334984318a42ea)

[RJVB (René Bertin)]

BUMP!

[mascguy (Christopher Nielsen)]

Add keyword portgroup, to pg-related tickets