[MacPorts] #51619: qt5.depends_component procedure

[MacPorts]

#51619: qt5.depends_component procedure
---------------------------+----------------------
  Reporter:  RJVB          |      Owner:  mkae
      Type:  enhancement   |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  qt5, qt5-kde  |
---------------------------+----------------------

Comment (by RJVB):

 Replying to [comment:13 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:
 > {{{
 > #!tcl
 > 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.

 > {{{
 > #!tcl
 > 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.

--
Ticket URL: <https://trac.macports.org/ticket/51619#comment:15>
MacPorts <https://www.macports.org/>
Ports system for macOS