CTK is a toolkit composed of three different kinds of modules:
Based on set of custom CMake macros and functions, CTK buildsystem allows to make the developer easier and increase its productivity.
Each one of these modules may have specific dependencies (like VTK, Log4Qt, QtMobility, ... ). CTK buildsystem provides the ability to checkout and build these external projects only if required. Note also that in some case, the developer want to use a local build of a given external project, this is also possible specifying the proper variable when CMake is invoked.
In addition to external projects, libraries, applications and plugins may also have inter dependencies.
Based on Superbuild, CTK is build in two steps:
- 1) Checkout and build external dependencies
- 2) Build CTK itself using the external dependencies build at step 1
In order to checkout the expected external project, the developer need to specify which module he wants to build at "configuration time" before even executing step1. Moreover, if application X is enabled, all dependent plugins, libraries, etc .. need to be enabled.
It means, dependencies of a given CTK module need to be done at time of step 1. To achieve that, dependencies of each module are specified within a file named target_libraries.cmake.
For example, the content of file CTK/Libs/Visualization/VTK/Core/target_libraries.cmake is the following:
# # See CMake/ctkMacroGetTargetLibraries.cmake # # This file should list the libraries required to build the current CTK libraries # SET(target_libraries VTK_LIBRARIES CTKCore )
Enabling and building dependencies
Before performing step1, the target_libraries.cmake file associated with each module is read. Then, the dependency graph is validated. If not error occured, the dependent modules and external projects are enabled.
The dependency graph is validated using a small tool named DGraph. This executable is a lightweight application also built by CTK buildsystem.
The DGraph tool helps also to: - obtain the topological order of the different module. This is later used by the dashboard driver script to build, test, compute coverage of each module in the correct order. - generate the project.xml file used to tell CDash what is the dependency graph.