Automates building separate (KDE) repositories in one go using plain CMake, similar to kdesrc-build.
The Superbuild CMakeLists.txt use features of recent CMake versions, so at least CMake 2.8.4 is required.
Each Superbuild consists entirely of subprojects (integrated via ExternalProject.cmake), that's why it is called a Superbuild.
During a Superbuild, the subprojects are downloaded from git (or svn, cvs, http, etc.), configured, built and installed.
h2. Selecting what you want
h3. Selecting the tag or branch
For selecting a specific tag from git, edit the SB_GIT_TAG cmake cache variable.
If you want to check out some subprojects in the superbuild with a different tag (e.g. "4.7" instead of "KDE/4.7"), for each subproject an individual tag can be used by setting a SB_GIT_TAG_<ProjectName> variable to the tag name. E.g. SB_GIT_TAG_KFoo would be the override for the project "KFoo".
h3. Selecting the subprojects
For each subproject there is a cmake option BUILD_<project>, which decides whether the respective project will part of the superbuild or not.
This applies not only to the actual building, but also e.g. for creating source packages (see below).
When a subproject is disabled, which another subproject depends on, a warning will be printed during the cmake run. If you do this, the depending subproject will try to find this dependency somewhere in the system, which may also be ok.
If you want to select exactly the subprojects you need for one application, disable all subprojects except that one application in cmake-gui, click Configure, and check for the warnings.
For each of these warnings enable the respective subproject, the Configure again. Repeat this until there are no warnings left. Now you should have the minimal selection of subprojects required.
One special note: the subprojects will be installed during the build. So you need to have write permissions to the install directory while building.
* run cmake on the Superbuild CMakeLists.txt
* select what you want (see above)
* set the CMAKE_INSTALL_PREFIX
* optionally, set LIB_SUFFIX, CMAKE_BUILD_TYPE
* run make
Dependencies between subprojects are also handled, so you can also directly "make Foo", and the subprojects Foo depends on will be built and installed first.
IF you need to specify additional arguments for cmake for all subprojects, you can set the variable SB_CMAKE_ARGS to this value, e.g. "-DFOO=foo -DBAR=Blub". This will be used as argument to cmake for all subprojects. If you need specific cmake arguments for some subprojects, you can for each subproject set a variable SB_CMAKE_ARGS_<ProjectName>, which will be used only for the specific project.
h3. DESTDIR handling
Setting DESTDIR is supported, but with some special conditions:
* if DESTDIR is set, CMAKE_SKIP_RPATH must be set to TRUE, because otherwise the resulting binaries will have RPATHs pointing into the DESTDIR locations
* DESTDIR must not be changed for a buildtree, i.e. it must always stay as it was during the initial cmake run
* DESTDIR must be an absolute path
There are also checks in the cmake files, which complain if DESTDIR is set, but to a relative PATH, and also during build it is checked whether DESTDIR is still the same as it was during the cmake run. So it will not fail silently, but you will notice.
h2. Creating source packages
This is useful e.g. for packagers who want old-style big KDE module tarballs instead of a gazillion of small separate tarballs.
It may be also useful for people who just want to build some part of KDE, and have exactly the sources needed for that in one tarball.
* set the cache variable SB_PACKAGE_VERSION_NUMBER to an appropriate version, e.g. via cmake-gui
* select what you want (see above)
* make UpdateAll
* make package
* -> now you have a tar.gz source package which can be unpacked and built anywhere
The UpdateAll target does not build anything, it only downloads the sources from git or wherever.
It is also possible to create again source packages from those source packages, which may contain just a subset of the subprojects contained in the source package.
If you simply want to create individual source packages, this is also possible.
By setting SB_ONE_PACKAGE_PER_PROJECT to TRUE, "make package" will create one source package per project. This actually is not a Superbuild anymore, but it may be useful for creating the selection of source packages you want.
|KDE Pim Runtime
h1. Extends the functionality of kdepim
* accountwizard - steps you through account creation for many resources
* Akonadi agents - calendarsearch, invitations, maildispatcher, nepomukfeeder and more
* Akonadi resources - birthdays, VCard contacts, CalDav, Google, ICal calendars, and many more
* Techbase project page - http://techbase.kde.org/Projects/PIM
* Apidox - http://api.kde.org/4.x-api/kdepim-runtime-apidocs