Anyway, good article. I’m planning to write something similar (playing with GNU autotools and heterogenous development environment…)

And I really like that idea, but am having problems getting it setup properly. Can you point to an example the CppUnit class setup and and linking things properly in cmake?

Thanks.

The Google C++ Testing Framework (googletest) supports producing JUnit-compliant XML reports. In my opinion it also adds the benefit of a cleaner way of defining and running the tests. Tests you define self register, and a test runner main method is provided that you can just link in.

Read more at http://code.google.com/p/googletest/

Please be aware that you might experience strange effects if both jobs happen to run in parallel. To avoid these problems, consider the use of the “locks and latches” plugin for hudson (http://hudson.gotdns.com/wiki/display/HUDSON/Locks+and+Latches+plugin). Using it, you can create a named lock that prohibits the parallel execution of the two jobs.
If you apply this to your solution, it’s a perfect way to have the speedup of incremental builds and the safety of regular clean builds.

If this “clean build” takes too long or you want to have a faster feedback one possibility apart from buying new hardware is to avoid the “clean build” in the majority of cases. Of course it is useful to have a “clean build” from time to be completely sure everything still works.

The solution I want to present here is to create a separate hudson job “CleanerJob” that does nothing else than deleting the build directory of the “WorkerJob” (the job we don’t want to do a clean build all the
time) at specific points in time.
I decided to delete the build directory at lunch time and at midnight.
For this I used a “Freestyle Hudson Job” and configured it like this:

I used the “cron-job execution feature”:

#Lunch time
45 12 * * *
#Midnight
0 0 * * *

Then I added a bash script that deletes the directory:
rm -rf <Build_Dir_WorkerJob>

The last thing to do is to change the script of the “WorkerJob” to avoid a clean build.

Change this:
># we want to have a clean build
> rm -Rf $BUILD_DIR
> mkdir $BUILD_DIR
> cd $BUILD_DIR

to this:

if [ ! -d "$BUILD_DIR" ]; then
mkdir $BUILD_DIR
fi

That’s it. The advantages of creating an additional hudson CleanerJob are these:
* Easy configuration of the “cleans” via the Hudson web-interface
* Manual clean via the Hudson web-interface possible
* Manual clean also possible by calling the Hudson “Build URL” of the CleanerJob
* You can set up Hudson to build the “WorkerJob” every time the “CleanerJob” has been executed (this way the project is built right after the build directory has been deleted)