qt5.depends_component procedure

[RJVB (René Bertin)]

This is a fork of ticket #50966

I would like to request the introduction of a procedure to facilitate declaring dependencies on specific Qt5 components in the Qt5 PortGroup, which would become almost a necessity once my qt5-kde port is committed. Such a procedure would make it possible for any port to depend on qt5 or qt5-kde (or qt5-devel or qt5-kde-devel) without having to figure out individually how to set up the path: style dependencies.

This procedure would remain in the wrapper/header Qt5 PortGroup once port:qt5-kde is committed, and come after the actual Qt5 PortGroup payload has been included.

Examples:

    qt5.depends_component qtbase qtsvg qt3d

would pull in the qtbase, qtsvg and qt3d subports from port:qt5 (or port:qt5-kde if that's the one installed).

or simply

    qt5.depends_component qt5 qtwebengine

would indicate a dependency on port:qt5 and port:qt5-qtwebengine (or port:qt5-kde and port:qt5-kde-qtwebengine). Being able to depend on the main port as a virtual component is required for ports where the dependency information from the Qt5 PortGroup is overridden, like it is in port:py-pyqt5.

The procedure also provides support for an *optional* table of dependency patterns that can be declared in the specific PortGroup (cf. qt5_component_lib in qt5-kde-1.0.tcl in #50966); this is the basis for depending transparently on the subports of either qt5 or qt5-devel.

I've been testing this procedure quite extensively with the new py-pyqt5 port.

NB: my KF5 PortGroup provides a comparable `kf5.depends_frameworks function which serves a comparable role (and makes dependency declarations quite a bit more readable).

[mkae (Marko Käning)]

What's the status of this? René, did you discuss this already on the dev-ML?

[RJVB (René Bertin)]

Status? No idea TBH. The procedure itself probably evolved a bit since I created this ticket, which I haven't kept up to date for lack of activity on it.

I did bring up the idea of using a wrapper around depends_lib to have a standard and above all clean way of declaring dependencies on Qt5 components that will work with both port:qt5 and port:qt5-kde (and port:qt5-kde-devel, for us if we never commit it) by hiding details like the appropriate path- style dependencies. I don't think there has been negative feedback.

It would make sense to introduce this (and incite port maintainers to use it) even before we start the introduction process for port:qt5-kde .

[mkae (Marko Käning)]

Okay, I guess a PR should be created, so that further discussion can start on GitHub, right? Especially needed with @mcalhoun being the maintainer of qt5!

[RJVB (René Bertin)]

Possibly.

What annoys me a bit here is that we'd be putting stuff in mcalhoun's PG which will later be moved to the common/header PG file.

The only way I see around that would be to introduce that common/header PG as qt5-1.1.tcl, which for now would simply include qt5-1.0.tcl plus define some relevant things from my own common/header PG file. For us it will be easy enough to convert all Portfiles to include the v1.1 Qt5 PG, but how acceptable would it be to make that change to all existing ports using Qt5?

[mkae (Marko Käning)]

That's a good idea. Let's go this way and see what the reviewers advise.

[RJVB (René Bertin)]

I'm not so sure, I think it's a good idea only if we can indeed upgrade all PortGroup qt5 statements ourselves (well, you, evidently).

If not, the problem with this approach is that it is likely to shoot us in the feet w.r.t. the drop-in replacement nature of qt5-kde. We're seeing it with cmake-1.1 already: what's the adoption rate of that? Of course that file is still in flux, but concerning new features that won't change anything for ports that don't require them. I'd hate to end up in a situation where we're told that we just have to provide our own PG and probably install qt5-kde in parallel.

[mojca (Mojca Miklavec)]

One warning. If ports can declare dependency on different versions of Qt (Qt 5.5 or 5.6 or dev or KDE or whatever ...) then the PortGroup needs to provide a way to automatically generate variants as well, otherwise there will be troubles with ABI compatilibility when users decide to switch to a different version of Qt.

[RJVB (René Bertin)]

A more important warning: when testing this procedure, please make sure to use the latest version from ​https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/qt5-1.0.tcl

# a procedure for declaring dependencies on Qt5 components, which will expand them
# into the appropriate subports for the Qt5 flavour installed
# e.g. qt5.depends_component qtbase qtsvg qtdeclarative
proc qt5.depends_component {first args} {
    global qt5_component_lib qt5.using_kde os.major
    # join ${first} and (the optional) ${args}
    set args [linsert $args[set list {}] 0 ${first}]
    # select the Qt5 port prefix, depending on which Qt5 port is installed
    set is_qt5kde [expr [info exists qt5.using_kde] && ${qt5.using_kde}]
    if {${is_qt5kde} == 1 || ${os.major} == 10} {
        # We have port:qt5-kde or we're on OS X 10.6 which only gets Qt 5.3.2 from that port
        set qt5pprefix  "qt5-kde"
    } elseif {${os.major} == 11} {
        set qt5pprefix  "qt55"
    } else {
        set qt5pprefix  "qt5"
    }
    foreach comp ${args} {
        set done true
        switch ${comp} {
            "qt5" {
                if {${is_qt5kde} == 1} {
                    global qt5_dependency
                    # qt5-kde-1.0.tcl exports the exact dependency expression in a variable
                    depends_lib-append ${qt5_dependency}
                } else {
                    depends_lib-append port:${qt5pprefix}
                }
            }
            "qtwebkit" -
            "qtwebengine" -
            "qtwebview" {
                # these components are never stub subports
                set done false
            }
            default {
                # these components are included port:qt5-kde (and provided as additional stub subports)
                if {${is_qt5kde} == 0} {
                    set done false
                }
            }
        }
        if {!${done}} {
            set portname "${qt5pprefix}-${comp}"
            if {[info exists qt5_component_lib] && [info exists qt5_component_lib(${comp})]} {
                # an explicit dependency pattern was given, e.g. path:foo
                depends_lib-append "$qt5_component_lib(${comp}):${portname}"
            } else {
                depends_lib-append port:${portname}
            }
        }
    }
}

@mojca: the goal here is not that ports can declare dependencies on different Qt versions. Even port:qt55 is supposed to be used only on earlier OS X version(s) (10.7 +?). How exactly that is supposed to work I don't know nor what kind of protection there is against installing that port on later OS versions; the procedure above assumes that this port is to be used on 10.7 only. port:qt5 and port:qt5-kde aren't supposed to have different Qt versions. Just as with -devel ports, it is largely up to the user to decide which Qt port s/he installs, and ports have to work with either of the available alternatives. But in line with your remark: using port:qt5-kde has always led to setting a variant.

Not that variants can protect against ABI differences when a dependency is changed ... The risk is mitigated a bit by Qt's guaranteed backwards compatibility, so everything should be fine as long as no one tries to use port:qt55 after having used a later Qt version.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Attached is a proposal for qt5-1.0.tcl.

To address some further questions:

• qt5-qtbase, qt56-qtbase, and qt5-kde all conflict with one-another
• qt5X-component depends on qt5X-qtbase (not a path dependency)
  • this way, there can be only one Qt installed at a time
• qt5.depends_component uses a path dependency
  • this way, a user can install qt5-kde and then install octave +qt5
  • this assumes that all the Qts are API compatible
• when qt5 (or qt5-kde) is upgraded and some systems are left behind, it is the responsibility of qt5 to include, e.g., replaced_by qt56 for those systems

With this setup, I do not believe automatic generation of variants is necessary.

[mojca (Mojca Miklavec)]

This doesn't make the variants unnecessary. If the buildbot built octave against qt5-qtbase and the user decided to install qt5-kde, then unless the two ports are fully ABI-compatible, this will still lead to problems.

There's one more thing. There is a very small number of ports from Qt 5.6 that breaks on 10.7, but even then most of them only break because they need C++11 and would probably work fine under libc++ default. So a pretty large population of 10.7 users might be OK with 5.6, while some users with particular needs might opt for 5.5 on the same OS version to be able to support some specific ports. I can imagine the same situation on other OS versions and a different set of Qt versions.

On the other hand I wouldn't even create a variant for Qt 5.7 on 10.6-10.7 and I wouldn't create a variant for Qt 5.5 on 10.9 for example.

Yes, variants are ugly, but probably the only way to make things work properly. (Just don't ask me how the user is supposed to switch between the variants. Actually having qt55-* co-installable with qt56-* at a different location would make things much easier and then users could even have both installed at the same time and pick a different variant for different ports if they would need that for some reason. We could perhaps one day install qt55 with stdlibc++ and qt56 with libc++ and then users of 10.7-10.8 could pick qt56 for C++11 projects and qt55 for everything else. Just brainstorming.)

In wxWidgets I used:

wxWidgets.setup wxWidgets-3.0 # or wxGTK-2.8 or anything else
depends-lib     ${wxWidgets.port}

but

qt5.depends_component qt5 qtwebengine

sounds OK to me. The components would then be selected based on the variant being used.

[RJVB (René Bertin)]

Replying to MarcusCalhoun-Lopez:

Attached is a proposal for qt5-1.0.tcl.

That has become a huge function!

A couple of points, I hope I'm concise enough:

• port:qt5 currently installs the pkg-config files to ${qt_libs_dir}/pkgconfig. Is that to be changed?

• I don't really like the "-append" suffix, if not only because it suggests there are also "-prepend", "-replace" etc. modifiers.

• qt5.using_kde isn't always defined, I don't know if [tbool qt5.using_kde] catches all possible situations(?) Evidently the variable could be defined by the shared PortGroup.

I am VERY much in favour of maintaining the PortGroup approach implemented in ​https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/qt5-1.0.tcl which allows us to keep separated the things that are best kept separated, like install locations and possibly variants. In that approach, qt5-1.0.tcl only contains the logic that decides which Qt5 port is (or is to be) installed and thus which dedicated PortGroup to load, as well as common functions like qt5.depends_component. This file could be called qt5-1.1.tcl as far as I'm concerned, but in that case we will have to do a forced upgrade of all PortGroup expressions in all dependent ports. Either way, with dedicated portgroups containing the port-specific logic the big switch in Marcus's proposal could be replaced with a lookup in a table that's defined in the dedicated portgroup. My own proposal already carries a prototype implementation of that. The advantage is that it keeps the shared PortGroup as lean as possible, AND let's each of us handle the depspecs details as best fits the port's main purpose.

• My own function above uses the is_qt5kde local variable to avoid adding dependencies on stub ports.

The qt5-kde stub ports are mostly there to be able to satisfy dependency requirements when someone moves from port:qt5 to port:qt5-kde . A user who installs port:qt5-kde from the start shouldn't be obliged to need them. The attached new proposal has a different effect: from what I can see it will add another (and different!) depspec on qt5-kde for each required component which is provided by port:qt5kde. That isn't very elegant and I don't know how "base" will handle the different path-style dependencies on a single port. A priori I think that this can be avoided by returning early from the default case (line 305 in the attachment); the qt5-kde PortGroup already adds a dependency.

qt5X-component depends on qt5X-qtbase (not a path dependency)

I suppose that's something that is handled in port:qt5 and port:qt55? The qt5-kde stubports evidently have a dependency on the port:qt5-kde.

[RJVB (René Bertin)]

Replying to mojca:

This doesn't make the variants unnecessary. If the buildbot built octave against qt5-qtbase and the user decided to install qt5-kde, then unless the two ports are fully ABI-compatible, this will still lead to problems.

Variant or not, if you replace a dependency with a non-ABI compatible alternative you will have problems. I'm not aware of anything in MacPorts that provides a 100% protection there. In my experience rev-upgrade isn't run systematically when you install a port (rather than upgrade), and never when you use de/activation. But even if it were it doesn't check the full ABI, just library presence, dependencies and compatibility version.

You can move from port:qt5 to port:qt5-kde, at least that's what my tests until now have shown. The KDE patches do introduce some ABI changes which may make moving back less evident, but this can be documented. I am also in the process of upgrading the port to Qt 5.7 because some KDE software already requires that Qt version. Qt's own ABI compatibility rules ensure that you can still move from port:qt5 (5.6) to port:qt5-kde (5.7), potentially breaking only ports that use private APIs. NB: I think Qt Creator uses a few private APIs, but it does so in a way that still allows you to run it after upgrading Qt to a new major version.

This is the reason my qt5-kde PortGroup declares and sets the +qt5kde variant when port:qt5-kde is used. That variant isn't intended to be manipulated by the user, it is just there as a label, and to allow the build-bots to provide binaries that are built against the ports' preferred Qt5 "flavour".

Make no mistake: the most important of my Qt5 KDE patches requires code to be built against port:qt5-kde because the preprocessor is involved and, yes, a subtle, behind-the-scenes change to an API.

Ports built against port:qt55 could be labelled the same way, with a +qt55 variant.

So a pretty large population of 10.7 users might be OK with 5.6, while some users with particular needs might opt for 5.5 on the same OS version to be able to support some specific ports. I can imagine the same situation on other OS versions and a different set of Qt versions.

Yes. The same question will arise with Qt 5.6 vs. 5.7 or 5.8 or higher. In fact, it almost arose for QtWebEngine already (5.7.0 didn't build on 10.9, 5.7.1 does but not with the preferred 10.9 SDK). I don't intend to provide a qt5-kde 5.5 version because a majority of KDE software now require Qt 5.6.2 as the minimal version. I try to keep the port set up so that it can be built on 10.7, either with libc++ or else using gcc, but I cannot test that myself so it is "officially unsupported".

On the other hand I wouldn't even create a variant for Qt 5.7 on 10.6-10.7 and I wouldn't create a variant for Qt 5.5 on 10.9 for example.

No. Qt 5.5 might have an interest on recent OS X versions for user developing for 10.7, but I don't think we have to cater to that particular niche.

Yes, variants are ugly, but probably the only way to make things work properly.

I agree, to the extent outlined above. I.e. variant(s) that label builds but nothing else. As you say, how should it work when a user has port:qt5 installed and then requests, say port install kf5-kwallet +qt5kde? Using path-style dependencies to allow different Qt5 ports to provide the necessary dependencies means there is no implicit conflict information in the depspecs, so all we can do is test for presence of the requested Qt5 port and raise an error if that fails.

I'm not sure if there's much point in that. For one, the KF5 PortGroup already checks which Qt5 is installed, and raises a big warning if it's not qt5-kde. I also have checks against variant_exists qt5kde and !variant_isset qt5kde; that's an error. I would have to think more (and hard) to see if there would be a point in defining the qt5kde variant for all qt5 dependents. But I'm pretty sure that is nothing much if anything to gain from allowing users to use +qt5kde as a way to impose port:qt5-kde. It's up to ports to indicate which Qt5 flavour works best for them (currently with set qt5.prefer_kde 1 before loading the portgroup). For the rest the choice should be made at the level of installing a Qt5 port and be as transparent as possible.

Actually having qt55-* co-installable with qt56-* at a different location would make things much easier and then users could even have both installed at the same time and pick a different variant for different ports if they would need that for some reason.

I have a hunch that concurrent installation will prove to be a Pandora's box and maintenance nightmare. With 2 monolithic ports (aka qt4-mac which just installs all of Qt4) this might still be doable, but with port:qt5 broken up into a growing number of subports the chances that things go wrong through unintended mix-and-match at build-time or even runtime are too high.

There's only 1 reason why one might want to have different "medior" Qt5 versions installed, and that's for development purposes. I think that goes beyond the intended scope of MacPorts. Qt already caters to that kind of need through its own installers, and I can tell from experience that it works fine to have a single Qt4,Qt5 pair installed through MacPorts and any number of other Qt versions in a different prefix and maintained through Qt's own installer (or via a Linux distribution's package manager). With a properly set-up QtChooser you can then even invoke QMake from the commandline and point it to whichever of your Qt versions you have installed and configured.

Side-note: there's an old submission ticket on Trac for QtChooser ...

We could perhaps one day install qt55 with stdlibc++ and qt56 with libc++ and then users of 10.7-10.8 could pick qt56 for C++11 projects and qt55 for everything else. Just brainstorming.)

Brain fart (O:-)): wouldn't those OS versions be really old and obsolete by the time we get around to considering how to achieve such a loft goal? ;)

In wxWidgets I used:

wxWidgets.setup wxWidgets-3.0 # or wxGTK-2.8 or anything else
depends-lib     ${wxWidgets.port}

Here we're talking about dependencies that aren't ABI compatible AT ALL, even use different backends that cannot be determined at runtime. The analogy here would be +qt4 and +qt5 variants, and indeed we *could* have a generic Qt portgroup that defines such variants which include the expected PortGroup. That could have made sense back in the day when Qt5 was still new and Qt4 still supported; I don't think there's much reason anymore to do this now.

qt5.depends_component qt5 qtwebengine

sounds OK to me.

The components would then be selected based on the variant being used.

No, not that please! That would defeat the whole effort to make the Qt5 ports drop-in alternatives so that users can decide what kind of experience they want simply be installing Qt5 one way or another.

• Want KF5 applications that work properly? Install port:qt5-kde, or just install any KF5 port from scratch. Other dependents on Qt5 will work fine but will be built from source (but there aren't many that are as complex and expensive to build as KF5).
• Don't care about KF5 applications but more about a stock Qt5 and getting binary installs from the build bots? Install port:qt5 or any non KF5 port that needs Qt5. If at some point a regular Qt5 dependent declares a dependency on a KF5 framework (say, KWallet support in QupZilla) you'll end up building the required KF5 frameworks from source and they'll work to an unknown degree. But you can always decide to migrate to port:qt5-kde, and the way things are done now this should not expose you to rebuilding or reinstalling everything.

To add to what I said above: I think that as soon as we do this, and start allowing users to set or unset +qt5kde to control what Qt5 flavour is to be used, we get hard dependencies on either port:qt5 or port:qt5-kde. That means we also have to start handling conflicts. There are over 60 KF5 Frameworks, a large part of which have intradependencies, and those frameworks are intended to be usable in code that has otherwise nothing to do with KDE. Handling this properly and not with a crude check will be a combinatorial nightmare.

[RJVB (René Bertin)]

And one last thing: that main KDE patch which introduces an ABI enrichment is designed to be submitted upstream. I've been in on-and-off contact with Qt devs about this for a long time, but upstreaming patches into Qt is a complex and difficult procedure, which in this case will need real-life proof of the value of a change that could have important implications for Qt's commercial customers.

Either way, the point is that there is some hope that this particular patch will be included upstream at some point (we're probably talking 5.9 by now ...). If so, it'll become available through port:qt5 too.

That will not remove all justification for port:qt5-kde, but it will mean that I can start offering more support for building KF5 code against a stock Qt5, and the ABI differences between port:qt5-kde and port:qt5 should disappear completely. It would be a pity to have to impose more or less crude conflicts and installation impossibilities and then to undo them.

Evidently, nothing stops Marcus from testing the patch in question on his end, and including it. It should be mature enough and not change significantly anymore (... soon ...). Just saying; that decision is his as much as the patch is mine :)

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to RJVB:

• port:qt5 currently installs the pkg-config files to ${qt_libs_dir}/pkgconfig. Is that to be changed?

Links to the .pc files are currently put into ${prefix}/lib/pkgconfig (see ​here).

• I don't really like the "-append" suffix, if not only because it suggests there are also "-prepend", "-replace" etc. modifiers.

You are right, the original name is probably best.

• qt5.using_kde isn't always defined, I don't know if [tbool qt5.using_kde] catches all possible situations(?) Evidently the variable could be defined by the shared PortGroup.

tbool ​tests for existence

I am VERY much in favour of maintaining the PortGroup approach implemented in ​qt5-1.0.tcl

I believe there would be strong objections from the other developers to having dependencies influenced by [file exists ${prefix}/include/qt5/QtCore/QtCore].
At the very least, it would run contrary to ReproducibleBuilds.
port deps libQGLViewer would give different answers from one day to the next depending on which Qt is installed.

The qt5-kde stub ports are mostly there to be able to satisfy dependency requirements when someone moves from port:qt5 to port:qt5-kde . A user who installs port:qt5-kde from the start shouldn't be obliged to need them.

I may have misunderstood how qt5-kde stubports are used, but I humbly suggest this is resolved after consensus is reached on general strategy.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Please correct me if I am wrong, but we have three major design goals:

1. Allow the installation of older versions of Qt to accommodate older OSs.
2. Support a patched version of Qt which is necessary to be used with KDE.
3. Minimal disruption of ports that use Qt.

Here are the options I can determine:

1. Let the user decide which Qt to install with reasonable defaults.
   • This seems to be the current path.
   • Runs contrary to ReproducibleBuilds and MacPorts philosophy in general.
   • There might be (and probably are) any number of ABI comparabilities that we don't know about.
2. Variants (qt5, qt56, qt5-kde) defined in qt5-1.0.tcl to conflicting Qts.
   • The various GTK ports had to jump through quite a few hoops with +x11 vs +quartz. The various maintainers have done a wonderful job, but, from the outside, it looked like quite a bit of effort. I am not sure I want to have allot of require_active_variants in client ports.
3. Variants (qt5, qt56, qt5-kde) defined in qt5-1.0.tcl to non-conflicting Qts.
   • Each Qt would be installed in its own location (${prefix}/libexec/qt5, ${prefix}/libexec/qt5-kde, etc.)
   • Potentially, lots of require_active_variants in client ports.
4. Completely separate qt5 and qt5-kde
   • Each Qt would be installed in its own location (${prefix}/libexec/qt5, ${prefix}/libexec/qt5-kde, etc.)
   • There would be a qt5-1.0.tcl and qt5-kde-1.0.tcl and each port would have decide which one to use.
   • Using qt5-1.0.tcl, the Qt version would be determined by the OS version and cxx_stdlib.
5. Attempt to merge qt5 and qt5-kde
   • The necessary KDE patches would be added via a variant in qt5.
   • The Qt version would be determined by the OS and cxx_stdlib.
   • require_active_variantsmight still be necessary in client ports, but probably not many.

If I understand correctly, Mojca has raised serious concerns about (1), and René has objected to (2) and (3).
Personally, I am leaning toward (4) or (5).
I must admit, however, that I do not understand the various ​KDE patches.
René has ​expressed reservations about (5).

Based on the numerous discussions we have already had, I thinks it is fair to say that a perfect solution is unlikely to present itself.
I am willing to work on any of the solution, but my order of preference is (5), (4), (1), (2), then (3).

[RJVB (René Bertin)]

Replying to MarcusCalhoun-Lopez:

Replying to RJVB:

• port:qt5 currently installs the pkg-config files to ${qt_libs_dir}/pkgconfig. Is that to be changed?

Links to the .pc files are currently put into ${prefix}/lib/pkgconfig (see ​here).

OK. I put those files into lib/pkgconfig directly.

I am VERY much in favour of maintaining the PortGroup approach implemented in ​qt5-1.0.tcl

I believe there would be strong objections from the other developers to having dependencies influenced by [file exists ${prefix}/include/qt5/QtCore/QtCore].
At the very least, it would run contrary to ReproducibleBuilds.

No, because of the variant I include. Build with a different Qt5 port installed and your port will be labelled with a variant, which makes it officially different from what the build bots give. KF5 ports set qt5.prefer_kde 1 before including the PortGroup. On the build bots and on virgin systems that means that port:qt5-kde will be installed, and the resulting build will have +qt5kde set. This will be exactly the same build on the bots, on a user system when installed from scratch, and on a user system where port:qt5-kde was already installed.

port deps libQGLViewer would give different answers from one day to the next depending on which Qt is installed.

All this is not so different from what you get with regular vs. -devel ports. Yes, port deps foo-qt5 will give a different answer depending on what Qt5 port is installed, but it's an answer that reflects the local context.

I don't see a way around this if we want minimal disruption of ports that use Qt5. Once a choice for Qt5 ports has been made, all Qt5 dependencies should be taken from that same choice: you shouldn't end up mixing qt5-qtbase and qt55-qtdeclarative for instance, nor qt5-kde with qt5-qttools to name just 2 examples.

We could probably make a more complex use variants and for the KF5 ports that could logic could be hidden (made automatic) in the KF5 PortGroup. But would we want to oblige users to specify a variant to "force" libQGLViewer or any other "pure Qt5" port to install when port:qt5-kde is installed? Or a variant to make it use port:qt55 on 10.7 if indeed that's the only way to get a proper Qt5 experience on that OS version?

I may have misunderstood how qt5-kde stubports are used, but I humbly suggest this is resolved after consensus is reached on general strategy.

Possibly, but in this case the fix is easy; the early return I mentioned above (i.e. don't add any dependencies for a component provided by qt5-kde it it's known we're using qt5-kde). That doesn't really depend on the kind of consensus we can reach.

[ctreleaven (Craig Treleaven)]

To state the obvious, variants suck. You all know why...only one variant can be the default. Thus the need for require_active_variants. And the buildbots (at least for now) only build the default. Thus we only serve binaries for the default--which is pretty important for something as large as Qt.

As an aside, the current implementation of require_active_variants isn't very friendly to novice users. The word "error" is repeated several time while masking the actual polite message to just reinstall port foo with variant +bar. My mythtv-* ports need require_active_variants and numerous times users have been convinced that the port is broken when they get this result.

[RJVB (René Bertin)]

Replying to MarcusCalhoun-Lopez:

Please correct me if I am wrong, but we have three major design goals:

I would use this order:

1. Minimal disruption of ports that use Qt.
2. Support a patched version of Qt which is necessary to be used with KDE.
3. Allow the installation of older versions of Qt to accommodate older OSs.

Here are the options I can determine:

1. Let the user decide which Qt to install with reasonable defaults.
   • This seems to be the current path.

Indeed.

• Runs contrary to ReproducibleBuilds and MacPorts philosophy in general.

Again, it doesn't have to violate the reproducible build approach as far as I understand it. It *is* somewhat of a novel approach for MacPorts, but then the situation is novel(ish) too. Though there are similarities with the libressl vs openssl situation (and I think I have prepared a more elegant implementation for port:qt5 vs port:qt5-kde!)

• There might be (and probably are) any number of ABI comparabilities that we don't know about.

The whole discussion about ABI compatibility has probably distracted us from a rather important point. This is a problem that plays only when changing from one port to another. Once you install port:qt5-kde, the +qt5kde variant my portgroup introduces is going to protect against pulling possibly incompatible binary builds from the bots. This means that users who install port:qt5-kde will install standard Qt5 ports from source, and when they change back to port:qt5 they may have to reinstall those ports. The same thing happens with GTk X11 vs. XQuartz as far as I know, or LibreSSL vs OpenSSL. It's a choice they make, and we can document such implications.

In practice I would expect that most users will decide once which Qt5 port they install and then stick to it.

2. Variants (qt5, qt56, qt5-kde) defined in qt5-1.0.tcl to conflicting Qts.
   • The various GTK ports had to jump through quite a few hoops with +x11 vs +quartz. The various maintainers have done a wonderful job, but, from the outside, it looked like quite a bit of effort. I am not sure I want to have allot of require_active_variants in client ports.
3. Variants (qt5, qt56, qt5-kde) defined in qt5-1.0.tcl to non-conflicting Qts.
4. Completely separate qt5 and qt5-kde

I am sure I do not want to have to impose the use of the active_variants PortGroup, and also that I don't want to have to guess about the side-effects of potentially having a different Qt version installed somewhere in the same prefix. Those 3 options will more or less oblige me to declare conflicts with port:qt5 in port:qt5-kde, and that's going to cause a big problem with ports like qca-qt5, poppler-qt5 etc. which are dependencies for both regular Qt5 applications and Qt5-kde applications.

5. Attempt to merge qt5 and qt5-kde
   • The necessary KDE patches would be added via a variant in qt5.
   • The Qt version would be determined by the OS and cxx_stdlib.
   • require_active_variantsmight still be necessary in client ports, but probably not many.

Require_active_variants would be required in all KF5 ports because there would no longer be a way to indicate a preference. Either way, the Option 5 ship has sailed over a year ago.

If I understand correctly, Mojca has raised serious concerns about (1)

Where? Mojca, is this true? I know you've been following my qt5-kde submission ticket from an early stage but cannot recall that you voiced any serious concerns there?

René has ​expressed reservations about (5).

Based on the numerous discussions we have already had, I thinks it is fair to say that a perfect solution is unlikely to present itself.
I am willing to work on any of the solution, but my order of preference is (5), (4), (1), (2), then (3).

My preference is evidently with the current approach, option 1). I've had a lot of time to think about this, and I think it's the only approach that allows to introduce KF5 in a way I can really stand behind. It's also the approach that puts the least additional maintenance effort on Marcus and maintainers of other ports depending on Qt5. I have already stated that I'm willing to carry the brunt of the maintenance of the shared PortGroup, but for the rest responsibility of everything related to the current port:qt5 will remain with Marcus, and I will keep in sync with any chances he makes that have implications for the compatibility between the ports. That's not just minimal disruption of ports that use Qt, it's also minimal disruption of all port maintainers except myself (but then guess who's proposing to introduce another Qt5 port :)). (There *is* the question of shared maintenance of the qmake5 PG of course but there too I have already re-organised the file to make it clear which parts are shared and which aren't).

The only other option I see is to include the QStandardPaths patch into port:qt5, without using a variant (just including the patch doesn't change Qt's default behaviour). That is probably the only adaptation for KF5 that is really required, though I cannot fathom nor guarantee how well things will work with the installation layout used by port:qt5 . They may simply work, but maybe they won't; the different and very non-standard location of the CMake modules may be an issue, for instance.

Actually, I do see another option, and that's to keep on proposing the KF5 ports as I do at the moment: as a custom ports tree with instructions on how to use it. But that would be somewhat of a pity.

[RJVB (René Bertin)]

Replying to ctreleaven:

To state the obvious, variants suck. You all know why...only one variant can be the default.

Among mutually conflicting variants, yes. More in general, only one set of variants can be the default.

It would also suck if users would have to add a variant to all KF5 ports they might want to install (including all 60+ frameworks), or if they would have to use a variant to force non-KF5 ports to install against port:qt5-kde .

Edit: another reason why variants suck: there is no way I know of for a port to unset a variant.

BTW, what happens when you do

default_variants +foo

before variant foo has been defined? Will that still work, or does the statement have to come after the variant has been defined?

Thus the need for require_active_variants ...

... actually goes a bit beyond that. It can be used for any combination of variants required. port:kf5-digikam for instance requires opencv +qt5+contrib, and only +qt5 conflicts with one of the port's other variants.

Thus we only serve binaries for the default--which is pretty important for something as large as Qt.

Those are actually the main arguments why Marko and I were almost relieved when it became clear that we'd better prepare a dedicated port:qt5-kde. It would make dependencies easier (and allow ports to express a preference rather than a hard requirement), but also allow the build bots to provide a binary build.

As an aside, the current implementation of require_active_variants isn't very friendly to novice users. The word "error" is repeated several time while masking the actual polite message to just reinstall port foo with variant +bar. My mythtv-* ports need require_active_variants and numerous times users have been convinced that the port is broken when they get this result.

I suppose you're entitled to feel welcome to change the message based on the feedback you've gotten!

[RJVB (René Bertin)]

A thought resulting from my reply to Craig:

suppose we have a shared Qt5 PG that determines which actual Qt5 port and PortGroup are to be used and which also defines a qt5kde variant. Suppose also that ports can do

default_variants +qt5kde
PortGroup qt5 1.0

instead of

set qt5.prefer_kde 1
PortGroup qt5 1.0

and be assured that [variant_isset qt5kde] is true in qt5-1.0.tcl .

I *think* that in that case, setting +qt5kde in ${prefix}/etc/macports/variants.conf will be analogous to deciding to use port:qt5-kde simply by installing it. In that case port deps will change it's output in reaction to a variant and not simply to what's installed (something I don't see the problem with but which may be unacceptable for that very reason 8-) ). I'll have to sleep a few nights over this and see how well I get used to the idea, but it's a solution I might be able to live with.

There's one big problem with this approach: how do we handle the situation where port:qt5 is installed, and a KF5 port or the user sets +qt5kde? The logical thing to do in that case would be

• if +qt5kde is the result of default_variants, unset the variant so that future tests [variant_isset qt5kde] will fail (but we can't)
• if +qt5kde is the result of +qt5kde on the commandline or in variants.conf, raise an error

Evidently the opposite situation is just as much a problem (though I'd hope there will never be a hard reason for ports to require the stock port:qt5).

I see that variants set through variants.conf show up as (+)foo while those set with default_variants as [+]foo. So at some level the difference can be made, but I don't know if that's possible in the Portfile.

PS:

tbool ​tests for existence

With interpreted languages it can make a considerable difference to avoid calls to user-defined procedures for frequent operations; dependency calculations can take long enough as it is already. Better ensure that the variable to be tested always exists in that case.

[mojca (Mojca Miklavec)]

It's easy to get lost in this discussion, I'll try to take more time to go through all of the points later.

I hope that one day a special KDE port will no longer be needed.

Do I understand correctly that qt5-kde is currently more or less qt5 + a bunch of modifications needed to run KDE apps and there would be no harm if everyone would use that patched version (or even better convince the upstream Qt 5 developers to include those patches and then there would be just a single version remaining anyway)?

But we'll certainly need special versions of Qt 5 for different OS versions and this is where we absolutely have to ensure that:

• Users don't end up with packages that were built with a different version of Qt (like having 5.5 installed and then installing a binary package that was built against 5.6).
• Ports declare dependencies in a proper way, so that the same port will depend on qt55-something on one system and on qt56-something on another without every single port implementing "if this is 10.7, then use qt55-something, if this is 10.8-10.10, use qt56-something, if this is 10.11 or later, use qt57-something".

[RJVB (René Bertin)]

Do I understand correctly that qt5-kde is currently more or less qt5 + a bunch of modifications needed to run KDE apps

More or less, indeed. There is at least 1 crucial patch (for getting "Linuxy" locations), there are a few patches which improve the experience like by allowing a different platform theme to be loaded automatically. There are also patches being developed upstream that address issues which are more likely to occur in KDE apps (related to using DBus, for instance), plus a number of patches for general little things that either were already in the old qt5-mac port when I started working on it or that come from Debian, and which still apply.

There is 1 other big difference, which may or may not be crucial: the installation layout. I've documented this extensively last year. In short, my approach follows Qt's implicit guidelines for installing different versions in parallel as system libraries in the same prefix. The old qtN-mac ports put the shared resources (plugins, mkspecs, etc) under a Linuxy location, /opt/local/share/qtN, and I remember running into issues with KDE4 when I tried to change that. So basically I kept all those old locations which never conflicted between the Qt4 and Qt5 ports, and that includes the CMake modules (as you already found out). I lack the resources to figure out if indeed this difference is crucial and to what extent. The point to keep in mind here is that KDE applications come from the FreeDesktop environment and are designed to interact with others from that same environment. That includes KDE4 and GTk/Gnome apps. Those all use /opt/local/share, so much hunch is that Qt5/KF5 applications best do the same in order to reach their full potential. It can of course be absorbed by using symlinks just as Marcus currently does with the pkgconfig files.

As a side-note: that kind of solution to make files appear in the location where they should be just increases filesystem clutter. It's an approach that can make sense if you're installing stuff without registry and you want to keep track of who installs what so you can uninstall/deactivate it with a few simple commands. With a package manager that knows exactly who installs what you can just as well put the actual files in the required location.

and there would be no harm if everyone would use that patched version

Indeed, I've always striven to ensure that the port can be used by everyone - I myself also use it for everything. That's one reason why the crucial ("QSP") patch is more complicated than it could be: just applying the patch itself changes nothing in Qt's behaviour. In its current version, software needs to be built with 1 or 2 tokens set in order to activate new feature the patch introduces. That's of course a sine-qua-none for upstreaming the patch, but just as much to me for acceptance into MacPorts.

(or even better convince the upstream Qt 5 developers to include those patches and then there would be just a single version remaining anyway)?

Yes. But I am doubtful that we can achieve that. There was momentum and a more or less open mind for the special needs of projects like MacPorts at some point, but that's probably almost 2 years ago by now. That time span and the fact the likes of Fink and HomeBrew haven't waited don't actually support my arguments. Getting patches into Qt is so difficult that there is at least 1 company that lives off it.

• Users don't end up with packages that were built with a different version of Qt (like having 5.5 installed and then installing a binary package that was built against 5.6).

Agreed. As discussed elsewhere this can be achieved by using a variant as a label. One or two things could be changed in "base" to streamline this, but it's already possible and this is actually the main thing that variants do in "base" (everything else depends on port-specific implementation).

I think that a solution to this point will also address (prevent) potential violations of the reproducible build principle.

• Ports declare dependencies in a proper way, so that the same port will depend on qt55-something on one system and on qt56-something on another without every single port implementing "if this is 10.7, then use qt55-something, if this is 10.8-10.10, use qt56-something, if this is 10.11 or later, use qt57-something".

OOPS, before the wrong idea gets in peoples' minds: Qt 5.7 still supports 10.9!! I'm working on upgrading to 5.7.1 as we speak! We'll see about 5.8, but even QtWebEngine 5.7.1 builds and runs fine (with 1 issue & patch I've reported upstream).

I guess it will shock no one if port deps foo-qt5 will return "qt55" on 10.7?

But just how shocking is it if that return value depended not simply on OS but also (or instead) on the installed Qt version? I can think of nothing in MacPorts dogma that forbids this explicitly. I also think it's certainly not illogical ("if you have qt55-base installed you should also depend on qt55-whatever if you need the whatever component"). It's even going to be necessary if qt55-* and qt5-* declare mutual conflicts, as they should.

Side-note: port:qt5-kde has had support for building Qt 5.3.2 on 10.6 for a long time now. This could and should maybe be moved to a dedicated port by now since KF5 has been requiring later Qt versions for a few iterations now.

[RJVB (René Bertin)]

A few more things, inspired by upgrading to 5.7.1 :

• qtenginio was deprecated in 5.6 and is removed from 5.7 . I doubt it was ever used but I am keeping its stubport (which will now raise an obsoletion error)

• A few new components were added in 5.7: QtCharts QtDatavis3D QtGamepad QtPurchasing QtScxml (no idea yet what the latter does). They're all small when built and only depend on other components in qt5-kde, so I am including it in the main port, with stubs.

• QtScript is deprecated but still available.

KF5 evolves rather quickly and is in a sense a development platform and showcase for new, "Kool" things. I think the only reason why it doesn't yet require Qt 5.7 across the board is because of Qt 5.6's LTS status. I know that many KDE devs are already using preview versions of Qt 5.8, and at least 1 port already requires 5.7. (Not to mention QtWebEngine which works better in 5.7+ than it does in 5.6 .) All this is in line with KDE's history of being a source of APIs that end up being integrated into Qt. This observation is actually an additional argument NOT to integrate the KDE patches with the main port:qt5 but to keep a dedicated Qt5 port so it become easier for KF5 ports to depend on port:qt5-kde, and for me to keep up with the "recommended" minimal Qt version.

It is also an argument for something I already hinted at before: the 2nd part of his qt5.depends_component proposal

        switch -exact ${comp} {
	            qtquickcontrols2 {
	                depends_lib-append path:lib/pkgconfig/Qt5QuickControls2.pc:${qt_port_name}
	            }
	            qtbase {
	                depends_lib-append path:lib/pkgconfig/Qt5Core.pc:${qt_port_name}
	            }
                    # ...
        }

should go into the port-specific PortGroup files, OR do a lookup in tables provided by those PortGroups.

Yes, I realise this degrades the ABI compatibility argument. But as explained above: 1 Qt guarantees that you can upgrade Qt from 5.x to 5.y without having to rebuild (except if certain private APIs are used) 2 the autodefault +qt5kde variant prevents getting mismatched binary builds from the bots.

[mkae (Marko Käning)]

Replying to mojca:

It's easy to get lost in this discussion,

Yes, I'm already lost in this and wonder which way we could and should go now...

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to mkae:

Replying to mojca:

It's easy to get lost in this discussion,

Yes, I'm already lost in this and wonder which way we could and should go now...

I am sorry about losing people in this discussion.
Hopefully, we can find our way forward.
Attached is a patch that attempts to satisfy most concerns.

• qt5 PG provides qt5kde variant (unless Portfile opts out).
• if qt5kde is selected, qt5-kde is required
• if qt5kde is not selected
  • path dependency on Qt component is used so qt5-kde could still satisfy dependency
  • default Qt port (qt55, q56, or qt5) is determined by values os.major and cxx_stdlib
  • if installed Qt is different than the default, a warning is given
• Only one Qt installation is possible at a given time
  • qt5-qtbase, qt56-qtbase, and qt5-kde all conflict with each other.
  • every Qt component (e.g. qt5*-qtmultimedia) explicitly depends on qt5*-qtbase (not a path dependency)

If there are no objections, I will commit the change, and we can proceed on other fronts.

[RJVB (René Bertin)]

I wouldn't commit anything just yet, in any event I won't have an occasion to take a detailed look until Monday. OTOH, if this is just to introduce qt5.depends_component and you don't mind making adjustments later, then fine. There will be more commits on the PortGroup level anyway, including for instance a mechanism by which (KF5) ports can express a preference for qt5-kde .

There is discussion going on on the devel ML ("Re: port:libressl vs port:openssl, path-style variants and prebuilt binaries") which evokes among other things the idea of adaptive depspecs. You should have seen it, and that Mojca is apparently rather on the same page as I am concerning the depspecs and (automatic) variant.

qt5 PG provides qt5kde variant (unless Portfile opts out).

Doesn't that means you can no longer prevent installing with qt5-kde installed? No variant provided means you cannot NOT set it and that seems counterproductive (opting out seems of interest only as a way to say "I don't work with that port").

if qt5kde is not selected

path dependency on Qt component is used so qt5-kde could still satisfy dependency

If that's not done with adaptive depspecs I will have to rectify that in the KF5 PG, idem with the preference mechanism. That'd be a shame, for functionality that should be provided at the Qt5 PG level.

every Qt component (e.g. qt5*-qtmultimedia) explicitly depends on qt5*-qtbase (not a path dependency)

Not the qt5-kde-* ports; those evidently depend on qt5-kde (including the stub qt5-kde-qtbase port).

[RJVB (René Bertin)]

I just think of an alternative for the PortGroup problem. I'm not yet sure whether I really like it, but it does have a certain appeal about it.

My idea has always been to have a shared qt5-1.0 PG which includes either qt5-kde-1.0.tcl or the as-yet-to-be-determined new name for the actual qt5-1.0.tcl as a function of the installed Qt version and/or the port's preference, followed by a common section containing for instance qt5.depends_component.

The alternative would be to have only 2 PGs, leaving qt5-1.0.tcl to Marcus, and qt5-kde-1.0.tcl to Marko and me. Each PG would then pass control over to the other when required by doing (in qt5-kde-1.0.tcl)

if {[port:qt5_is_installed]} {
    PortGroup qt5 1.0
    return
}

and in qt5-1.0.tcl

if {[port:qt5_is_installed] || [variant_isset qt5kde]} {
    if {[port_opts_out]} {
        return -code error "Incompatible qt5-kde port installed"
    } else {
        PortGroup qt5 1.0
        return
    }
}

This control transfer would have to take place near the top of the PortGroup, but can be preceded by any definitions that we would like to be available always.

This would probably solve the preference indication issue implicitly. A preference for port:qt5-kde would be indicated by requesting the qt5-kde PG, insofar as that PortGroup might in fact include the other PortGroup if this preference cannot be respected. Generic Qt5 ports can continue to include the qt5 PG and still end up using qt5-kde if that port is installed. The appeal is that we will each have more leeway in the choice of the exact implementation like for instance qt5.depends_component which means it wouldn't have to implement "adaptive depspecs".

The crucial condition here is of course that we must both agree to transfer control to the other PG when that is dictated by the installed Qt5 port or user preference indicated in some other way.I have no problem with that (it's what I'm aiming at already) but I would have preferred to shoulder that responsibility (through a shared PG) and not burden others with it because unhappy changes could cause considerable breakage in KF5 functionality. It will probably be necessary too to protect the PGs against loading them multiple times to avoid unexpected situations where for some reason the 2 PGs are loaded in succession.

We might do something similar for the qmake5 PG too.

[RJVB (René Bertin)]

So... comments on the 2nd proposal, I have some idle time but offline and only the diff open in a web browser. More idle time than I thought, so this has become another exhaustive message.

General reaction: this really looks more complicated than necessary, and something that I myself would not like to have to maintain. It also makes my previous idea of going for just 2 Qt5 PGs each of which jumps to the other when necessary much more appealing. It will leave us both with much more freedom to do things the way we consider best, hardly any common code to maintain but just a generic principle of not breaking the other port's functionality. I've already aligned qt5-kde to a few important choices that I would have preferred doing without (separate component subports for instance), I think I could make a few "strong suggestions" how to implement the qt5/qt5-kde co-habitation :) Esp. since I've been studying the question for about a year now (and I am the one without commit access to repair things quickly when required).

I think we should concentrate now on providing a qt5.depends_component function that works for port:qt5 (qt55 etc), and rectify things later as things become clearer. port:qt5-kde will still have to go through whatever review process is waiting for it. The main importance is that ports can begin to declare depspecs in a future-compliant manner.

That means there's quite a bit of code in the proposal that concerns a port that doesn't exist yet, and which may have to be changed later on. Or simply removed because never used (for instance because the corresponding case will always be handled in qt5-kde-1.0.tcl).

Another general remark: let's not assume too hard yet that a port:qt56 will become *necessary*. There will never be a qt56-kde for instance if enough KF5 projects drop support for Qt 5.6 .

More specific points:

• Let's use a simple, short and all-lowercase namespace. I'm not convinced that there's any need to have a namespace for things supposed to be used only inside the PG files (which is what Qt5PortGroup suggests). Evidently this critique is moot if the namespace isn't intended to be used in dependent ports (and I can thus use my own).

My own approach with namespaces and PGs is this: anything "private" that's not supposed to be used by ports (the ones depending on Qt5, excluding port:qt5* and port:qt5-kde) is put inside a real namespace, anything that's intended for use by ports in a "fake" namespace. That would give qt5::something_private and qt5.depends_component.

• I'm not at all convinced either that the check for the installed Qt5 version/flavour has to be done in the pre-configure. I cannot judge for port:qt5 vs qt55 vs qt5x but detecting qt5x vs. qt5-kde doesn't even require to query the registry. Simple file existence checks can tell those ports apart, and that will always be faster than querying the registry. Rule of thumb: this kind of code is evaluated in dependency calculations, which can already take a lot of time for highlevel ports with lots of dependencies. As maintainers we're the first concerned by that aspect.

• what does port::register_callback do?

In general I think that the approach with a function that is called in addition to qt5.depends_component is maybe very elegant and all, but it looks like overkill. In the end you're using a lookup table run in interpreted code, which takes about just as much space as writing a hard-wired table like for the checksums. With a table there's no need to write a function that registers the entries and its pretty certain that Tcl code that just defines and sets an internal variable type executes much more efficiently than a user-written procedure. I think you're using qt5_private_components as a sort of cache to make register_dependents a bit more efficient, but I wonder if that isn't more complexity with little benefit (other than keeping the maintainer's neurones in shape each time maintenance is required :) ).

• I like my qt5.using_kde variable better than qt5.kde_variant, and a few ports are already using qt5.using_kde. The latter would be appropriate as a shortcut for port:qt5 +kde while the former is a shortcut for "we're using qt5-kde". I don't think there's any point in making it an "option" either (i.e. a procedure in disguise) because it only has 2 sensible values. Again, efficiency and simplicity.

• proc qt5.depends_component {first args} {}

AFAIK this will require 2 arguments at least; the short way to write a procedure to that requires at least a single arguments is proc qt5.depends_component {first {args 1}} (i.e. set a special default value for the 2nd argument).

I hope that's about all...

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to RJVB:

I think we should concentrate now on providing a qt5.depends_component function that works for port:qt5 (qt55 etc), and rectify things later as things become clearer. port:qt5-kde will still have to go through whatever review process is waiting for it.

If that is what you want.
I will create the qt5.depends_component procedure without worrying about qt5-kde.

[RJVB (René Bertin)]

Want, want, want ... my point is a bit that we don't yet have a clear picture of what we want ... in terms of best compromise. I think it's best to keep things as simple as possible, and for now that might indeed mean not bothering with a port that doesn't yet exist.

The main thing now is to have a qt5.depends_component function that works for your port so that dependent ports can start using it to ease the integration of port:qt5-kde. In the future that function can be refactored as needed so that it works with all possible Qt5 ports, without changing the API of course.

One thing I didn't check: did you foresee a way to pull in your meta-port, i.e. the appropriate port:qt5 or port:qt55, etc? My proposal did that with qt5.depends_component qt5, and that syntax is in fact used in port:py-pyqt5 (with a minimal embedded copy of qt5.depends_component). In my mind this means "all of Qt5 except WebKit and WebEngine" because they're so big and the latter is a replacement of the former. But we could also agree on qt5.depends_component all which would include all subports.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 70f320f9/macports-ports:

qt5 PG: add qtkde variant if requested

See #51619

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 8feef8ae/macports-ports:

qt5 PG: add procedure to create deps on Qt components

Fixes #51619

[RJVB (René Bertin)]

Replying to MarcusCalhoun-Lopez:

In 70f320f9/macports-ports:

qt5 PG: add qtkde variant if requested

See #51619

I thought we had agreed that there would not be anything related to qt5-kde committed yet?!

The mechanism for requesting qt5-kde as I designed it uses qt5.prefer_kde, and qt5.using_kde is set only if qt5-kde is indeed used, that is, if the preference could be respected.

I had also strongly suggested that qt5.using_kde should be a normal Tcl variable, for simplicity.

Ports are supposed to instruct the Qt5 PG what they expect from it, and that means setting a variable before the PG is loaded, much like port:qt5 and port:qt5-kde set building_qt5 before loading the PG. Using an options variable for that is overkill that makes things more complex for everyone. Fortunately qt5.using_kde was never meant to be used for this and there's still time to make adjustments.

Let me make something very clear here. I do not want to see a repeat of the situation of a year or so ago where I see all my work and carefully thought out mechanism be changed, after having exposed it for months without feedback, and without being able to rectify anything because I don't have commit access. That's no basis to work with, and that could ultimately mean there will be no KF5 ports in MacPorts.

We're not yet at that point, let's not get there at all.

[mkae (Marko Käning)]

In 648c5dad/macports-ports:

kchmviewer: upgrade to 7.7 based on qt5

• pure Qt version of this application
• KDE variant is skipped for now, as it requires KDE4
• moved from category x11 to devel
• use of qt5.depends_component not yet possible ( See: #51619 )
• use absolute paths for libzip & libchm ensuring using of correct libs

Closes: #53097
Closes: ​https://github.com/macports/macports-ports/pull/110