[MacPorts] #52922: qt5 @5.6.2_0: build errors on 10.7

MacPorts noreply at macports.org
Sun Nov 20 23:01:47 CET 2016


#52922: qt5 @5.6.2_0: build errors on 10.7
-------------------------------------------------+-------------------------
  Reporter:  mojca                               |      Owner:
                                                 |  MarcusCalhoun-Lopez
      Type:  defect                              |     Status:  accepted
  Priority:  Low                                 |  Milestone:
 Component:  ports                               |    Version:
Resolution:                                      |   Keywords:  lion
      Port:  qt5 qt5-qtdoc ​qt5-qtmultimedia     |
  qt5-qtserialbus qt5-qtwebengine qt5            |
  -qtwebengine-docs qt5-qtwebkit qt5-qtwebkit-   |
  docs qt5-qtwebview qt5-qtwebview-docs          |
-------------------------------------------------+-------------------------

Comment (by RJVB):

 Replying to [comment:6 MarcusCalhoun-Lopez]:

 > As soon as qt5 is upgraded not 5.7, I also planned on creating a qt56
 port as it is has [https://blog.qt.io/blog/2015/12/18/introducing-long-
 term-support/ long term support].[[BR]]

 This has already been discussed on Trac or the ML; the consensus was that
 maintaining support for 5.6 only makes sense if newer Qt versions drop
 support for OS X versions that we'd like to continue to support. But if
 10.8 support is dropped only in Qt 5.8, why would we maintain a Qt 5.6
 port if we could just as well maintain 5.7 as our own LTS version?

 I would personally prefer to maintain platform-specific maximum versions
 in a single Portfile as much as possible, but that is less cumbersome for
 me since qt5-kde uses only 3 distfiles at the moment.

 > If it was a bad idea, others [https://github.com/Homebrew/homebrew-
 versions/pull/1191 have made the same mistake], so at least we are in good
 company.

 I'm not sure if HB is good company in this aspect :)

 > I would suggest the following solution: in {{{qt5-1.0.tcl}}},

 > In Portfiles, replace dependency {{{port:qt5-qtbase}}} with
 {{{path:lib/pkgconfig/Qt5Core.pc:${qt_name}-qtbase}}}.[[BR]]
 > This would be fairly minimal change that would also allow us to finally
 commit qt5-kde since it is a drop-in replacement.[[BR]]
 > I have a script that makes the changes to Portfiles.

 That's comparable to but considerably more complicated and less readable
 than my solution. We may end up with something similar, but we're not
 there yet.

 With my proposal, Portfiles can just use expressions like

 {{{
 qt5.depends_components qtsvg qtdeclarative qttools qtwebkit
 }}}

 to declare dependencies on anything that is not added automatically by the
 actual PortGroup. If port:qt5-kde (or port:qt5-kde-devel, in my or Marko's
 case) is used this translates to

 {{{
 depends_lib-append
 path:libexec/qt5/Library/Frameworks/QtCore.framework/QtCore:qt5-kde \
     path:libexec/qt5/Library/Frameworks/QtWebKit.framework/QtWebKit:qt5
 -kde-qtwebkit
 }}}

 because only QtWebKit has its own real subport (there's no point in
 installing stubs ports if it can be avoided).

 otherwise it translates to

 {{{
 depends_lib-append path:lib/pkgconfig/Qt5Core.pc:qt5-qtbase \
     port:qt5-qtsvg \
     port:qt5-qtdeclarative \
     port:qt5-qttools \
     port:qt5-qtwebkit
 }}}

 (or idem with qt55 instead of qt5 on 10.7)

 Port:qt5-kde indeed installs the .pc files in the same location as
 port:qt5, but it would not be wise as a general rule to allow ports to mix
 and match Qt components from port:qt5-kde and port:qt5. Path-style
 dependencies work great, but they only allow the user to install an
 alternative port explicitly. If the requested dependency is not already
 provided, it is still the port specified after the colon that will be
 installed, and that shouldn't be `port:qt5-foo` instead of `port:qt5-kde-
 foo` or vice versa.

 > > It might have been more useful to investigate whether C++11 support is
 sufficient in GCC 4.7+ to build at least QtWebKit on 10.7.
 > You seem to have made progress in building Qt with MacPorts compilers,
 but to me, Qt seems very intent on using OS compilers.[[BR]]
 > With such a large piece of software as Qt, I would prefer to stay as
 close to the supported configuration as possible.

 Actually, I think they only do that because they consider that it's the
 only compiler that people have available, and at some point there must
 have been a reason not to rely on the clang proxies installed in /usr/bin.
 Do you have explicit statements of the contrary?

 > Please correct me if I am wrong, but isn't QtWebEngine already a subport
 in both qt5 and qt5-kde?[[BR]]
 > Are you suggesting that we create a new Portfile?[[BR]]

 Yes, it is. It does however not contain anything specific to KDE, but it
 will very likely drop support for older OS X versions quicker than the
 rest of Qt, meaning an additional OS/Qt version aspect to manage.

 > Is my proposed solution above sufficiently easy for Portfile maintainers
 to use?[[BR]]

 Not really IMHO. To summarise:
 - maintainers will have to specify the path:-style dependencies explicitly
 - the installed "flavour" would have to be made available in `qt_name` to
 avoid all (future) possibility for untested mix-and-match

 > It seems to fit in with standard MacPort practices.

 Yes, and evidently the wrapper I add on top of it just hides the more
 cumbersome aspects of those practices.

 I have implemented a similar wrapper to specify dependencies on KF5
 frameworks (there are 60+ of those...) and it makes it both much easier to
 specify a list of dependencies and to read the resulting Portfiles. All
 you have to deal with are names of components (frameworks), no need to
 bother with prefixes and names of the files that indicate whether they're
 installed or not.

 In any case, we must come to an agreement on solving the PortGroup hurdle
 via a header PortGroup that includes the actual PortGroup (and includes
 some shared stuff).
 If that solution is retained, I'd propose myself as the principal
 maintainer of that header PortGroup (which doesn't and won't change
 anything in the way port:qt5 works). It seems only fair that I'd bear the
 brunt of the extra work, and I have been able to be more reactive in
 addressing issues in the recent past.

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



More information about the macports-tickets mailing list