[MacPorts] #49780: provide an interface for ports to depend on Qt5 components

[MacPorts]

#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