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

MacPorts noreply at macports.org
Sun Nov 20 22:16:16 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          |
-------------------------------------------------+-------------------------
Changes (by MarcusCalhoun-Lopez):

 * status:  new => accepted


Comment:

 Replying to [comment:4 RJVB]:
 > Was that really necessary?!
 I would argue that is was a good idea.[[BR]]
 Qt 5.5 was the last version of Qt that officially supported 10.7.[[BR]]
 Further, there was a rather significant jump between Qt 5.5 and 5.6.[[BR]]
 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]]
 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.

 > Now dependents ports are going to have to determine what Qt5 port to use
 if they wish to support OS X 10.7 but not require a libc++ enabled OS.
 I would suggest the following solution: in {{{qt5-1.0.tcl}}},
 {{{
 # standard Qt5 name
 global qt_name

 if { ![info exists qt_name] } {

     if { ${os.major} <= 7 } {
         #
         # Qt 5 does not support ppc
         # see http://doc.qt.io/qt-5/osx-requirements.html
         #
         set qt_name qt53
         #
     } elseif { ${os.major} <= 9 } {
         #
         # Mac OS X Tiger (10.4)
         # Mac OS X Leopard (10.5)
         #
         # never supported by Qt 5
         #
         set qt_name qt53
         #
     } elseif { ${os.major} == 10 } {
         #
         # Mac OS X Snow Leopard (10.6)
         #
         #     Qt 5.3: Deployment only
         # Qt 5.0-5.2: Occasionally tested
         #
         set qt_name qt53
         #
     } elseif { ${os.major} == 11 } {
         #
         # Mac OS X Lion (10.7)
         #
         # Qt 5.6: Deployment only
         # Qt 5.5: Occasionally tested
         # Qt 5.4: Supported
         #
         set qt_name qt55
         #
     } elseif { ${os.major} <= 12 } {
         #
         # OS X Mountain Lion (10.8)
         # OS X Mavericks (10.9)
         # OS X Yosemite (10.10)
         # OS X El Capitan (10.11)
         #
         # Qt 5.7: Supported
         # Qt 5.6: Supported
         #
         set qt_name qt5
         #
     } elseif { ${os.major} <= 16 } {
         #
         # macOS Sierra (10.12)
         # as of Qt version 5.7, there is no official support
         #
         set qt_name qt5
         #
     } else {
         #
         # macOS ??? (???)
         #
         set qt_name qt5
         #
     }
 }
 }}}
 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.

 > 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.

 > I also hope to get an answer on my suggestion to split off QtWebEngine.
 It may no longer be necessary to turn that split-off into a multi-
 versioned port with 10.7 in mind, but it will likely require special
 treatment of 10.9 sooner than we'd like.
 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]]
 If so, I would prefer to keep it a subport.[[BR]]
 If fits in well enough with the machinery that exists in the qt5 Portfile.

 > The lack of versioned dependencies in MacPorts would make it really
 cumbersome to manage multiple Qt5 ports for different 5.x versions in
 addition to qt5-kde in a way that is transparent enough that other port
 maintainers will actually consider using them.
 Is my proposed solution above sufficiently easy for Portfile maintainers
 to use?[[BR]]
 It seems to fit in with standard MacPort practices.

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



More information about the macports-tickets mailing list