[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