Upstream supports build with Qt 5, but we do not handle this in the ebuild which is causing problems. Did we ever agree on how we are going to handle this? I seem to remember talk of qt4 and qt5 USE flags. In any case I imagine we will need a patch to avoid the current automagic situation, which I can take care of and push upstream. CMakeLists.txt: > find_package(Qt5Core QUIET) > if (Qt5Core_FOUND) > find_package(Qt5Gui REQUIRED) > find_package(Qt5Widgets REQUIRED) > find_package(Qt5Sql REQUIRED) > find_package(Qt5Network REQUIRED) > find_package(Qt5Xml REQUIRED) > find_package(Qt5DBus REQUIRED) > find_package(Qt5Test REQUIRED) > set(QT5_BUILD TRUE) > > include("cmake/modules/ECMQt4To5Porting.cmake") > include_directories(${QT_INCLUDES}) # TODO: Port away from this. > > if (CMAKE_VERSION VERSION_LESS 2.8.9) > message(FATAL_ERROR "Akonadi Qt 5 build requires at least CMake version 2.8.9") > endif() > > set(QT_QTTEST_LIBRARIES Qt5::Test) > else() > find_package(Qt4 REQUIRED) > include(${QT_USE_FILE}) > endif()
As a side note, FindQt5Transitional.cmake which is bundled by a number of packages is also automagic so we need to patch that. Sput says that lives in either kdelibs (frameworks) or extra-cmake-modules.
(In reply to comment #1) > As a side note, FindQt5Transitional.cmake which is bundled by a number of > packages is also automagic so we need to patch that. Sput says that lives in > either kdelibs (frameworks) or extra-cmake-modules. Hmmm...I thought qt5 shipped the "official" cmake files itself, so what is FindQt5Transitional exactly and why are they bundling it?
(In reply to comment #0) > Did we ever agree on how we are going to handle this? I seem to remember > talk of qt4 and qt5 USE flags. Yeah I think we need to introduce qt4 and qt5 USE flags for packages supporting both versions.
(In reply to comment #3) > (In reply to comment #0) > > Did we ever agree on how we are going to handle this? I seem to remember > > talk of qt4 and qt5 USE flags. > > Yeah I think we need to introduce qt4 and qt5 USE flags for packages > supporting both versions. seconded, especially because it's not possible to link a library to qt5 and it's consumer to qt4 or vice-versa. Additionally I've seen weird behaviour with akonadi-server; it was linked to qt-core4 and other pieces of qt-5. It compiled but obviously nothing worked.
(In reply to comment #4) > seconded, especially because it's not possible to link a library to qt5 and > it's consumer to qt4 or vice-versa. > Yep, so we need something like (R)DEPEND="dev-libs/libfoo[qt4(+)=,qt5(-)=]" and REQUIRED_USE="^^ ( qt4 qt5 )" or, if qt support is optional REQUIRED_USE="?? ( qt4 qt5 )"
I wonder, is it necessary to introduce both qt4 and qt5 flags? Could we not just assume qt4 if the qt5 flag is not enabled?
Strictly speaking, that would work, but we have a qt4 USE already, and I think it's better if the user explicitly rather than implicitly selects the Qt version.
We must be sure to set a default then.
(In reply to comment #8) > We must be sure to set a default then. +1
Qt team said that there should be separate qt4 and qt5 flags, with "select only one" logic where appropriate for the package.
Some initial Qt5 consumer work has been done in the KDE overlay: akonadi-server: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commitdiff;h=35e8e60c7e469359540fb3c4a209844b66fd5d81 libattica: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commitdiff;h=a594105647d515bc3468e5238b86c4c56708d55a
