CDash Build Dashboard: use it!
As tokoe prefers screenshots in blogs, let’s start with one:
This is a screenshot of the current kdepimlibs build status on CDash. In the first column you can see the different build setups that have committed a build. There are builds from FreeBSD, SunOS, Linux, with different kind of CMake versions and differnt versions of GCC.
After that you can see the results of the different stages of the build: Update, Configure, Build and the Tests. The ‘Min’ column indicates how long that stage took. The most interesting column for me are the warnings in the build section. I’m trying to get that number down to the real warnings, removing all the non interesting warnings. On some line you can see 8 with -20 just below it. That means that in the last run the amount of warnings dropped from 28 to 20. Simalary you can see that there currently is a build error on one of the build machines…
CDash provides the possibility to subscribe to projects, with that subscription you can automatically receive build errors if you like to. You can also indicate that you only want to receive mail when your svn account is one of the possible causes of a build failure.
Contributing your build to the dashboard is easy. Just start your build as usual with cmake. Then instead of typing ‘make’, type ‘ctest -D Experimental’. It will build it and upload the data to CDash automatically.
So, next time your build fails and you need help on IRC, you might as well through your build on CDash and put the link to your build on IRC. Nightly builds are also important. It would be nice if we get as much as possibile different setups to report there. That would make releasing a KDE SC easy, as we can have detected build errors on certain platforms in a very early stage.
Summarized:
- Please contribute builds to dashboards
- Subscribe to build errors for your pet project
- Module maintainers should monitor their module
- If you have a minuted, fix some build warnings, it is fun!
Why such old cmake on Linux while newer one on freebsd?
It is good to test compilation also with the minimum cmake version kde supports. That way we can detect usage of features of cmake which are not supported in older versions of CMake while KDE should still build with it.
Does this works with every KDE module?
And should we put this in our build script to use it every time?
“make Experimental” should also work insted of “ctest -D Experimental”.
It works in most kde modules, simply see if there is a CTestConfig.cmake there. As it is should be a separate clean build to catch all the warnings, it does not integrate completely in the current workflow. I’m still not sure what the best way is, I’m sure someone else can answer it better than me. I just run it in a module when i want to work on a module, but nightly builds would be best i guess.
http://my.cdash.org/viewDynamicAnalysis.php?buildid=45116
Anyone know where those are and how to fix the mem leaks ?
Why 2.6.2 ? Because this is the version required to build KDE (since 4.2.0 up to 4.4.x).
If you are interested in contributing Nightly builds, please drop by on kde-buildsystem@kde.org and I’ll help you setting it up.
Currently there are dashboards set up for:
* kdesupport
* kdelibs
* kdepimlibs
* kdepim
* kdebase
* kdeutils
* kdeexamples
* kdeadmin
* kdeaccessibility
There’s no special reason why there is no dashboard for the other modules yet, I just didn’t get around to set them up yet.
We’re still fiddling around with setting up fine grained email notification in case of issues (which we have currently every day), so this will still improve.
Alex
It’s weird, I don’t see data anymore on the dashboard, I only see ‘No update data as of 2010-01-16T14:00:00 EST’
Hit ‘previous’, their daybreak moment is not obvious ;-)
@Toma,
Ok, thank you :)
I will be talking about this today at Camp KDE. I think this is something we should be adding to more KDE modules, and I will be adding my machine when I get back home.