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