qt4 vs qt5 build for dependencies
David Faure
faure+bluesystems at kde.org
Fri Apr 5 09:27:03 UTC 2013
When I ported attica, soprano, libdbusmenu-qt and other such "kdesupport-
level" dependencies to Qt5, I used
find_package(Qt5Core QUIET)
if (Qt5Core_FOUND)
message(STATUS "Building with Qt5 support")
...
else()
find_package(Qt4 REQUIRED)
endif()
i.e. use Qt5 if it's in the user's environment (CMAKE_PREFIX_PATH) otherwise
look for Qt4.
I thought this was perfect, it made things "work out of the box" without any
manual intervention, for both types of users.
And it didn't require a separate branch for the qt5 support (we only have this
in a few modules which started to use qt5 stuff, but for for the majority of
modules, there's no active development, so branching is not wanted).
Now here's the problem: nowadays distros are starting to have Qt5 in /usr,
i.e. it's being found automatically. Which makes it impossible to build this
code for Qt4.
So I'm afraid I have to drop the idea of automatic detection, and let people
choose explicitely. My current idea would be to reintroduce -DQT5_BUILD=true
(like we had in kdelibs at some point; but this discussion isn't about kdelibs
obviously), i.e. default to the Qt4 build, since that's what KDE SC releases
are still about.
Later on, when we're about to release KF5, we want to turn this around, i.e.
make it easy to build things for Qt5, and if we still need qt4 support at that
point, adding a -DQT4_BUILD=true (and dropping the QT5_BUILD variable,
obviously).
Opinions? Better ideas?
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks
More information about the Kde-buildsystem
mailing list