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, [email protected], http://www.davidfaure.fr Sponsored by BlueSystems and KDAB to work on KDE Frameworks _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
