From KDE TechBase

This page has been archived
The information on this page is outdated or no longer in use but is kept for historical purposes. Please see the Category:Archives for similar pages.

What is a dashboard ?

A dashboard can show the results of Nightly and Continuous builds of a software package. This includes warnings and errors from the configure and build process as well as the results of the executed tests belonging to the software package. This is not only displayed for one machine, but ideally for all supported operating systems such results are submitted, also with different configurations, e.g. one for a minimal system with most optional features disabled and one for a full featured system.

For KDE CDash-based dashboards are set up at, a service provided by Kitware. CDash only displays the results, the actual building and testing is done decentral on other machines. When failures occur, like build errors or failed tests, notification emails can be sent by CDash. So by building and testing KDE each day on the supported platforms and collecting the results in a central place, we can make sure that KDE stays compiling and also working on all supported platforms.

You can help too to increase the quality by setting up a Nightly build and submitting the results to

For which modules/packages are there dashboards ?

Currently there are dashboards set up for all modules of KDE, and one for kdesupport. There are not yet dashboards for extragear. If you are interested in setting dashboards up for these too, just go to and do it, or ask on the kde-buildsystem mailing list if you have any questions.

So, here comes the list of currently existing KDE dashboards:

How to set up a Nightly build

Setting up a Nightly build and this way contributing to keep KDE working is not hard.

You need:

  • A computer. It should be running the Nightly build every day, at some time after 20:00 CET (for the Nightly builds the state of the repository at 20:00 CET is used).
  • A KDE development environment installed on this computer, i.e.
    • CMake >= 2.6.2, >= 2.8.0 is recommended for the Nightly builds (better warning and error reporting)
    • Compiler etc.
    • Subversion client
    • Qt4 and the other required libraries for building KDE4
  • Some time to maintain the Nightly build, i.e. to upgrade the required libraries, e.g. Qt4 when necessary, to install new required libraries etc.

Under Unix

This applies to Linux, FreeBSD and other Unixes. It should also apply to Mac OSX, but this hasn't been tested yet. You can figure out how to set up the Nightly builds yourself, but we have also something prepared to make it really easy. Let's assume you want to contribute a Nightly build for the kdeutils modules. That's how you do it:

  • Go to and register
  • Once registered, subscribe to the kdeutils project
  • Checkout trunk/quality/nightly-support/ from KDE svn. There, in the KDE/ subdirectory is a ctest-script ready to use for each KDE module.
  • Write a shell script which sets the CMAKE_PREFIX_PATH environment variable so that CMake will find everything required and then execute ctest with the KDEUtilsNightly.cmake script. This will look something like the following:

 ctest -V -S /where/you/checked/out/KDE/KDEUtilsNightly.cmake,KDE_CTEST_BUILD_SUFFIX=gcc-4.2.3

That's it basically. The -V option for ctest makes ctest verbose, so you can see what it's doing. The KDE_CTEST_BUILD_SUFFIX will be appended to the buildname displayed at Setting it to the used compiler is a sensible choice.

  • Set up a cron job which runs this script every day:

 $ crontab -e
 00 22 * * * /where/is/my/script/

That's it. Probably you first want to run the script manually a few times until everything works, but after that you can just have it executed via cron. The next day you should then see your results on

If you want to contribute Nightly builds for more than one KDE module, it gets a little bit more complicated. You have to make sure that the modules are built in the right order, and that the modules are installed correctly, if other modules depend on them. For examples see kdesdk/cmake/nightly-support/example-scripts/, e.g. Nightlys-2.6.2 is the shell script I use on my machine to build (and install where necessary) all KDE modules on my Linux machine.

Under Windows

Nobody has done this yet for KDE AFAIK, but it should be quite similar. If you intend to do this, please contact the kde-buildsystem mailing list, we will do our best to get it working quickly.

How to get notification emails

So, you don't want to/cannot submit a Nightly build, but you want to receive notification emails from CDash if the compilation of one of the projects fails or if test cases fail.

If that's the case, you need to

  • Go to and register. You will get a confirmation email.
  • Once you have a valid login at, go there
    • Login
    • Click the "My CDash" link in the top left corner
    • Then, click "Show public projects"
    • Search the project you are interested in and click "Subscribe"
    • Go to the "Email preference" and "Email category" tabs and configure what emails you want to receive.

That's all. Now you should receive notification emails whenever problems in this project occur.


More fine grained email notifications

In order to be really useful for KDE, we need more fine grained email notifications. CDash supports "subprojects", and users can register to get emails just for subprojects. Setting up these subprojects currently needs quite some manual work:

It would be nice to have a CMake command which takes a list of project()-names and generates the CDash-subproject files, with correct dependencies etc. for them. This needs work in CMake itself.

Extended viewing methods in CDash

Currently in CDash you can see everything for one project at once. For KDE we need an additional mode: see everything for one operating system or submitted by one host, also to multiple projects, at once. This way e.g. our Windows contributors would have a quick way to get an overview how KDE is doing on Windows today. This needs work in CDash.

Dependent builds

Building of some modules should be triggered when other modules have changed, e.g. when kdelibs has been built all other modules should be built. This needs work on the CTest-scripts which drive the Nightly builds.

How to get help

If you have any questions regarding Nightly or Continuous builds for KDE or about CDash or CTest in general, please ask on the kde-buildsystem or kde-core-devel KDE mailing lists, or also on the CDash mailing list.