Simplify handling of (dual-)Qt in the build system
authorManuel Nickschas <sputnick@quassel-irc.org>
Wed, 19 Mar 2014 20:00:07 +0000 (21:00 +0100)
committerManuel Nickschas <sputnick@quassel-irc.org>
Wed, 19 Mar 2014 20:00:07 +0000 (21:00 +0100)
commit5b43f2776fa53bfe15a5b3b4398dfe3e931d5802
tree14c711b32218cc8881b357296a7fdae0bbc15b40
parent0de0a17782cf478d638a532f36898197af88e0bc
Simplify handling of (dual-)Qt in the build system

We've used a somewhat complex way to link the various targets to the
required Qt libraries (and use the correct defines and CFLAGS...), because
when that stuff was written, there were no target properties in CMake, and
thus it was not easily possible to build targets within the same scope with
different settings. Therefore, we couldn't use the QT_USE_FILE and had to
write our own library handling.

These days, target properties exist, and Qt5 came up with a nice way to attach
the needed properties based on the Qt modules in use: qt5_use_modules()
This was later backported to Qt4, too, replacing the old way of having to
include QT_USE_FILE which would then set global variables.

We now make use of this; because qt4_use_modules() only showed up in
CMake 2.8.10, we've copied that function. It will be used only if it's
not present in CMake proper.

As a bonus, I've also wrapped all the qt-related macros into functions
that do the check for the Qt version we want to build against, and select
the proper macro to call, thus removing lots of WITH_QT5 conditionals
from the rest of the build system. Note that Qt5 support is still incomplete,
anyway.
CMakeLists.txt
cmake/QuasselMacros.cmake
src/CMakeLists.txt
src/client/CMakeLists.txt
src/common/CMakeLists.txt
src/core/CMakeLists.txt
src/qtui/CMakeLists.txt
src/uisupport/CMakeLists.txt