From: Manuel Nickschas <sputnick@quassel-irc.org>
Date: Sun, 23 Mar 2014 01:39:38 +0000 (+0100)
Subject: Completely rework the dependency handling in the build system
X-Git-Tag: 0.11.0~92
X-Git-Url: https://git.quassel-irc.org/?a=commitdiff_plain;h=2273a95ba9c277ce6dd7a67158a3d3ed9f161182;hp=2273a95ba9c277ce6dd7a67158a3d3ed9f161182;p=quassel.git

Completely rework the dependency handling in the build system

Traditionally, optional build dependencies are handled in CMake via
offering options and conditionally searching for the needed packages.
This leads to having lots of options, boilerplate for telling the user
which features are enabled or not, unclear handling of automagic
dependencies, and so on.

These days, CMake offers a much nicer way: feature_summary() and friends.
To make use of this, one calls find_package unconditionally and then sets
properties on the package that tell CMake if the dependency is optional
or required, its purpose, a description of the package etc. At the end
of configuration, CMake then displays a nice summary of all the packages
searched for and (not) found, as well as other features.

Quassel now makes use of this modern way of specifying dependencies, replacing
most of the former options (they're still there, but unused now, and will
be removed soon). Note that one can still disable an optional dependency Foo by
passing -DCMAKE_DISABLE_FIND_PACKAGE_Foo=TRUE to CMake.

I also took the opportunity to radically clean up and fix how we handle
dependencies throughout the build system:

* We no longer set an extra CMake variable to indicate that a package was
  found, but use the Foo_FOUND variable directly
* Compile definitions and include directories are no longer set globally
  in the root CMakeLists.txt, but in the Quassel modules where they're
  actually needed; this should speed up compiling ever so slightly and
  generally make things much cleaner
* Libraries are now linked directly to the Quassel modules that use them,
  rather than to the executable. This prepares us for making the modules
  shared libraries at some point, and is anyway The Right Thing™ to do
* Fully support Qt5 in the build system, including finding the proper version
  of dependencies where appropriate and available

Note that the changes to the build system are not complete yet, and some things
may be broken now. Note also that while Qt5 is now supported in the build system,
the code itself still requires many changes to actually compile with Qt5,
so don't even try.
---