A few months ago I set out to build my first hudson plugin. It was an interesting, sometimes difficult journey which came to a good end with the CMake Builder Plugin, a build tool which can be used to build cmake projects with hudson. The feature set of this first version was somewhat limited since I applied the scratch-my-own-itch approach – which by the time meant only support for GNU Make under Linux.
As expected, it wasn’t long until feature requests and enhancement suggestions came up in the comments of my corresponding blog post. So in order to make the plugin more widely useable I used our second Open Source Love Day to add some nice little features.
Update: I used our latest OSLD to make the plugin behave in master/slave setups. Check it out!
Let’s take a walk through the configuration of version 1.0 :
1. As in the first version you have to set the path to the cmake executable if it’s not already in the current PATH.
2. The build configuration starts as in the first version with Source Directory, Build Directory and Install Directory.
3. The Build Type can now be selected more conveniently by a combo box.
4. If Clean Build is checked, the Build Dir gets deleted on every build
5. The advanced configuration part starts with Makefile Generator parameter which can be used to utilize the corresponding cmake feature.
6. The next two parameters Make Command and Install Command can be used if make tools other than GNU Make should be used
7. Parameter Preload Script can be used to point to a suitable cmake pre-load script file. This gets added to the cmake call as parameter of the -C switch.
8. Other CMake Arguments can be used to set arbitrary additional cmake parameters.
The cmake call will then be build like this:
/path/to/cmake \ -C </path/to/preload/script/if/given \ -G <Makefile Generator> \ -DCMAKE_INSTALL_PREFIX=<Install Dir> \ -DCMAKE_BUILD_TYPE=<Build Type> \ <Other CMake Args> \ <Source Dir>
After that, the given Make and Install Commands are used to build and install the project.
With all these new configuration elements, the CMake Builder Plugin should now be applicable in nearly every project context. If it is still not useable in your particular setting, please let me know. Needless to say, feedback of any kind is always appreciated.
Schneide Blog 
Hey,
I have trouble using this hudson plugin with git. I have tried both the hudson mailing list and the irc channel, without success. Maybe you can help me:
I have a simple hudson job, checking out a local git repository and supposedly building it with your CMake plugin. It fails and the output is:
Checkout:workspace / /var/lib/hudson/jobs/build-helloworld/workspace – hudson.remoting.LocalChannel@1f5b38e
Last Build : #19
Last Built Revision: Revision b6b13ae02c124d97c9266ee40e0144d96ff84c52 (origin/master )
Checkout:workspace / /var/lib/hudson/jobs/build-helloworld/workspace – hudson.remoting.LocalChannel@1f5b38e
Cloning the remote Git repository
Cloning repository origin
$ /usr/bin/git clone -o origin /var/git/helloworld.git/ /var/lib/hudson/jobs/build-helloworld/workspace
Fetching upstream changes from /var/git/helloworld.git/
[workspace] $ /usr/bin/git fetch /var/git/helloworld.git/ +refs/heads/*:refs/remotes/origin/*
[workspace] $ /usr/bin/git ls-tree HEAD
Seen branch in repository origin/master
Commencing build of Revision b6b13ae02c124d97c9266ee40e0144d96ff84c52 (origin/master )
Checking out Revision b6b13ae02c124d97c9266ee40e0144d96ff84c52 (origin/master )
[workspace] $ /usr/bin/git checkout -f b6b13ae02c124d97c9266ee40e0144d96ff84c52
[workspace] $ /usr/bin/git tag -a -f -m “Hudson Build #20” hudson-build-helloworld-20
Recording changes in branch origin/master
[workspace] $ /usr/bin/git log –numstat -M –summary –pretty=raw b6b13ae02c124d97c9266ee40e0144d96ff84c52..b6b13ae02c124d97c9266ee40e0144d96ff84c52
MODULE: /var/lib/hudson/jobs/build-helloworld/workspace
Build dir : /var/lib/hudson/jobs/build-helloworld/workspace/build
CMake call : /usr/bin/cmake -G “Unix Makefiles” -DCMAKE_INSTALL_PREFIX=/var/lib/hudson/jobs/build-helloworld/workspace -DCMAKE_BUILD_TYPE=Debug “/var/lib/hudson/jobs/build-helloworld/workspace/source”
[build] $ /usr/bin/cmake -G “Unix Makefiles” -DCMAKE_INSTALL_PREFIX=/var/lib/hudson/jobs/build-helloworld/workspace -DCMAKE_BUILD_TYPE=Debug /var/lib/hudson/jobs/build-helloworld/workspace/source
Finished: FAILURE
I first tried to make sure that git is working correctly, so instead of building CMake, I setup a shell command running doxygen – that works just fine. Next I tried to verify that my CMake files are setup correctly, and did the following: I cloned the git repository manually in my user folder using
$ git clone /var/git/helloworld.git/ workspace
I then fixed permissions such that hudson has read write access to the folder workspace. In hudson, I setup the build task entering /path/to/workspace/source as “source folder” (as there is a folder called source in my git repo) and /path/to/workspace/build as my “build directory”. I cleared the field “install directory” as I do not want to install and in advanced options cleared the field “install command”. I then ran the task and it worked. I double checked the folder, the Makefile and the executable were generated correctly.
So it seems as if both the git plugin and the cmake plugin in itself work fine, but not in combination with each other, and the above console log does not give me any clues on whats going wrong. The workspace folder is also always empty when I check it (is that the normal behavior?)
Any ideas on what I am missing here?
Okay, the problem seems to be that the cmake plugin needs the install command, and I did not have any install config in my CMakeLists.txt. I have it up and running now.
Thanks for your feedback! You’re right, “Finished: FAILURE” is not really chatty 😉 The next version will have some more meaningful error message.
I tried to setup a situation where error messge “Finished: FAILURE” is the only output when trying run a build. Seems that this happens only when “cmake” cannot be executed (e.g. beacuse it’s not in PATH). So I added a check for the cmake executable to the plugin. Check out version 1.1.
BTW, everything went fine when I removed the install command and the install config from my CMakeLists.txt, so there must have been another reason for your problems.
Thank you for creating CMakeBuilder.
Has anyone tried this on a master/slave system? I have a Unbuntu master and a OS X slave. During my first runs, I got:
Started by user anonymous
Building remotely on macmini
Updating svn://192.168.11.3/dev/cpp/afengine
At revision 626
no change for svn://192.168.11.3/dev/cpp/afengine since the previous build
MODULE: /Users/hudson/workspace/afengine/.
Cleaning Build Dir… /Users/hudson/workspace/afengine/bld
Directory could not be created: /Users/hudson/workspace/afengine/bld
Finished: FAILURE
———————————-
I thought the Directory could not be created error was caused by user permissions. svn was able to check out the entire path tree okay as user Hudson on the OS X slave. I tried many things on the OS X slave including chmod a+rw on the path down the tree and even creating the bld directory by hand. Nothing worked.
However, when I create entire tree on the Ubuntu master, I started getting a different error message:
Started by user anonymous
Building remotely on macmini
Updating svn://192.168.11.3/dev/cpp/afengine
At revision 626
no change for svn://192.168.11.3/dev/cpp/afengine since the previous build
MODULE: /Users/hudson/workspace/afengine/.
Cleaning Build Dir… /Users/hudson/workspace/afengine/bld
/Users/hudson/workspace/afengine/src
Finished: FAILURE
———————————-
which is fine, because I didn’t create that directory on the Ubuntu master. I browsed the open source code down to line 33 in CmakeBuilderImpl.java, where the IOException() was thrown, but I don’t know enough about Hudson plugins and the conventions for ensuring that the code is executed on the slave and not on the master.
I hope I am not chasing this problem down the wrong path. If anyone has any suggestions and/or work-arounds, please do post. Thank you.
– Ken
Just to say that i’ve had the same problem as Ken: “Directory could not be created”. I’ve also double checked permission on the slave, tried to create the builddir myself… but i was not able to find any way of making it work.
I’m having trouble with “Directory could not be created” as well. I’m using hudson with a unix slave node and it seems to be taking the WORKSPACE environment variable value from the master windows machine, thus trying to create build directory under C:\hudson\workspace\
I am having the same problem as Attet but we are using Mac OS
Any Idea when this issue will be resolved or a work will do.
Thanks
Can this plugin be used without cmake to just kick off Make and record the output?
Sure, you could point the plugin to a fake cmake executable, like an empty shell script. Then only “make” and “make install” would be called.
A simpler solution, though, would be to just use a shell script build step instead of the cmake plugin.
Hello!
Great work! Thank you a lot!
Do you intend to use CTest results as Hudson input?
Thanks.
Regards.
No, not in the near future. But some kind of integration of CTest would certainly be very nice.
I would like to try, at least something really simple for now. I may need some help, do you have some time and patience? 🙂
Regards.
I didn’t see a bug tracker for cmakebuilder so I’m hoping to get noticed here. I made a small patch that a) fixes build type dropdown not remembering previously selected value and b) propagates environment variables to the cmake and make commands so that parametrized builds can be used.
Patch at http://pastebin.com/QenkZ3w3
Hey Atte, thank you very much for your patch! I integrated it right away and released plugin version 1.3.
Great plugin, I have found one annoying issue, and one possible improvement:
– the configure panel forgets the Debug/Release/MinSizeRelease setting each time I edit the configuration, so if I change something else, my build always switches back to a Debug build.
– the advanced ‘extra arguments’ gets full very quickly, and is only a single-line field. Multi-line would be better, or even better a key=value list (like for environment variables / tools in other places in Hudson configuration)
Hey James, the issue with the build type has been fixed with the newest version 1.3 of the plugin (thanks to Atte for his patch).
Thanks for the improvement proposal for the ‘extra arguments’ field. I will certainly consider changing it into multi-line for the next release.
An absolutely awesome plugin for Hudson, I must say. I found that if I don’t put anything in install directory, the build will not work.
So I have to put something in the install directory field and then clean the field for install command.
Perhaps the plugin can check and skip the install step when install directory is not set.
Thanks for the hint. I will look into it for the next version.
I’d love to get the 1.3 version so I can use Bullseye code coverage testing. It requires setting the COVFILE environment variable and I’ve been going nuts trying to figure out why the 1.2 version wasn’t getting it. Is there an hpi file or do I need to build from svn?
Thank for this great plugin! CMake-Integration is now very easy in hudson.
However, there is another feature request 😉
I use the custom configuration possibility of cmake and have non-standard configuration names, such as Bla_Release, Foo_Release. Unfortunately the combo box shows only the standard configuration types. Would it be possible to make a editable combo box?
Thank you in advance!
Hi,
I’ve installed the plugin but when I configure a job I don’t see any UI that looks like it allows cmake build steps. In particular, there’s nothing about cmake listed in the “Add Build Step” menu. Am I missing something really obvious?
Thanks!
If you chose ‘Build a free-style software project’ on the ‘New Job’ page, ‘CMake Build’ should appear in the ‘Add Build Step’ menu. Otherwise, something is possibly wrong with your hudson installation.
Oh, I have multi-configuration (matrix) projects. Is there a reason this plugin couldn’t work in that context?
Hm, I have not tried multi-configuration projects, yet. But right now, I can’t think of a reason why the plugin should not work in matrix builds. I will look into that
I’m trying to build an alternate target, such as “make test”. I tried adding a “test” as “Other CMake Arguments” but anything it that field seems to be ignored.
Changing the “Make command” to “make test” works, however it gives an error that there is no such executable.
What is the correct way to make alternate targets and pass arguments to the make step?
Running plug-in version 1.5, Hudson version 1.367 on Cent OS 5.4.
Hello,
I get the following exception with the new version (2.6):
FATAL: null
java.lang.NullPointerException
at hudson.plugins.cmake.CmakeBuilder.perform(CmakeBuilder.java:164)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601)
at hudson.model.Build$RunnerImpl.build(Build.java:174)
at hudson.model.Build$RunnerImpl.doRun(Build.java:138)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
at hudson.model.Run.run(Run.java:1258)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:129)
Btw do you have a changelog?
Thanks for the great plugin, it is very helpful to me!
Leo
Hello,
I am getting exactly the same Exception with the new version.
Kind regards,
Benjamin
Hi Benjamin, hi Leo,
thank you both for your feedback. Volker, the author of the plugin, is currently on holiday and will be back within two weeks. I am sure he will fix the problem in a timely manner then. Until then, can you revert to the previous version if it works for you? Sorry for the inconvenience caused.
I will try to look at the code in a few days. If I find the problem, I’ll release a new version of the plugin.
I’ve just looked at the code and perhaps I’ve found the problem.
If you can, grab the locally built cmakebuilder plugin version here:
http://www.softwareschneiderei.de/download/public/cmakebuilder.hpi
and install it manually to your hudson. Please tell me if your problem is gone.
Sorry for the inconveniences.
Hello Daniel,
thank you for your response. The new plug-in works for me.
Kind regards,
Benjamin
Hello Daniel,
works for me too.
Thanks a lot!
Leo
Hi, I had the exact same problem (nullpointerexception) and this fixed it, thanks a lot 🙂
Hello,
With the new version 1.6.1, I get the same exception than with the version 1.6.0 :
FATAL: null
java.lang.NullPointerException
at hudson.plugins.cmake.CmakeBuilder.perform(CmakeBuilder.java:167)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601)
at hudson.model.Build$RunnerImpl.build(Build.java:174)
at hudson.model.Build$RunnerImpl.doRun(Build.java:138)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
at hudson.model.Run.run(Run.java:1273)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:137)
I downloaded the version 1.7 from http://www.softwareschneiderei.de/download/public/cmakebuilder.hpi
and it’s OK with this version, every thing works fine.
I looked for differences between versions 1.6.0 and 1.6.1. I got the following result :
$ diff -r cmakebuilder_1.6.1/src/hudson/plugins/cmake cmakebuilder_1.6.0/src/hudson/plugins/cmake
diff -r cmakebuilder_1.6.1/src/hudson/plugins/cmake/CmakeBuilder.java cmakebuilder_1.6.0/src/hudson/plugins/cmake/CmakeBuilder.java
68c68
String otherBuildType,
79,82c79
< this.otherBuildType = otherBuildType;
< if (null == this.otherBuildType) {
< this.otherBuildType = "";
this.otherBuildType = otherBuildType;
$
I presume that modifications around otherBuildType between versions 1.6.0 and 1.6.1 are not those of the version 1.7. But, without the sources of the version 1.7, I can’t checked differences.
Anyways, thanks for your pluging.
Best regards,
Eric
Hi Eric,
the difference code you pulled should prevent the NullPointerException from 1.6. – and does so in my environment. To be sure, I did a blank slate test with the newest hudson version (1.377) and the plugin version 1.6.1 installed from the hudson plugin manager. Worked fine, too.
I fixed the problem in another way with release 1.6.2. Let me know if this works for you.
Hello,
Sorry to answer you so late, I just saw your message today.
I have tested your last release 1.6.2 with the Hudson version 1.379 and it works fine.
Thanks again for your work.
Best regards,
Eric
Hello,
just another feature request for this great plugin:
We are using a UNIX/Windows mixed environment with hudson salves. A per-slave configuration for the location of cmake (currently only in the system configuration) would be nice to respect the different systems.
Thanks,
Leo
Hi Leo,
Better late than never! Version 1.8 provides two more means to set the cmake executable path:
1. option “Job specific CMake path” in job configuration
2. environment variable CMAKE_EXECUTABLE
The environment variable can be set per slave which should solve your problem.
Hello,
I try to use version 1.8 of the plugin on WinXP, but when starting a job it complains about an unknown method. May be that “Z” should not be there, see javas stack trace below.
FATAL: java.lang.String.isEmpty()Z
java.lang.NoSuchMethodError: java.lang.String.isEmpty()Z
at hudson.plugins.cmake.CmakeBuilderImpl.preparePath(CmakeBuilderImpl.java:72)
at hudson.plugins.cmake.CmakeBuilder.perform(CmakeBuilder.java:167)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:603)
at hudson.model.Build$RunnerImpl.build(Build.java:172)
at hudson.model.Build$RunnerImpl.doRun(Build.java:137)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:417)
at hudson.model.Run.run(Run.java:1362)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Sorry, after some mor googling I found that this method requires Java 1.6. But currently I am using Java 1.5.
So problem solved.
I’m using CMake to generate solution files and then trying to build with MSBuild.
Unfortunately I can’t get the syntax right. If I enter arguments on the “Make Command” line it complains about not finding the file (and arguments) in the path. If I put the arguments on the “Install Command” line like I do with nmake, then the log shows that MSBuild is run without arguments.
I’d just like to know if anybody has done this before I start digging in code. (I love open source!)
Thanks,
Chuck
I have the same problem here. I cannot get it right to put an argument in the “Make Command” line.
Actually I thought I do not need one, as I was convinced, that cmake build plugin figures it out, to put the solution file as argument to the “Make Build” command (if its a Visual Studio Build), but this is not the case.
And simply calling msbuild in the build directory leads to the problem that it can’t figure out what to build, as .sln and .vcproj are all put in this directory:
MSBUILD : error MSB1011: Specify which project or solution file to use because t
his folder contains more than one project or solution file.
Does anyone has a solution for that problem?
Hey,
Just wondering if you were still supporting the cmake build plugin for Hudson.
The “Other CMake Arguments” does not expand variables, including the $WORKSPACE.
Thanks
Hi!
First. Thanks for the plugin.!!!
Question is .. I want to build my project with make command, but also with the argument “-j 3” (to make parallel compiling).
but if you set the “Make Command” to “make -j 3” jenkins says “There’s no such executable make -j 3 in PATH: /usr/local/sbin, /usr/local/bin, /usr/bin, /usr/sbin, /sbin, /bin.”
can you help me please?
You see that output on the configuration page, right? You can ignore that and save the configuration anyway. During the build it should do the right thing.
Thanks!!!!!!!
Thank you for the great plugin! I am currently evaluating it in a virtual master-slave configuration.
I need to set the necessary paths and variables to use Visual Studio 2010, normally I’d just run vcvarsall.bat. How can I integrate this into the jenkins-cmake-build-setup? Is there a more elegant way to use Windows 7/VS10 as build slave?
Good timing! I’m currently looking into that a little closer.
So you are using cmake’s “NMake Makefiles” generator? You can call external programs and set environment variables from CMakeLists.txt files. Maybe you could work with that?
Hi, thanks for the fast reply!
Yes, I use the “NMake Makefiles” generator. This allows me to use the msvc compiler and all other visual studio things from the command line. I don’t see a way to use “Visual Studio 10” because this will generate no makefiles but only *.sln-solutions. If someone has found a way to use .sln files, I’d be happy to learn about that.
Calling external programs from within CMake won’t help in my case, as I need to set the variables to access the compiler and stuff BEFORE I call CMake. CMake needs to find the compiler. The first thing CMake does, is to detect the compiler. This fails if the variables are not set correctly.
Currently I’m using manually created batch-files, but I would really love to use a native CMake integration. I think that is much smarter.
It should be enough to prepend some arbitrary batch/shell-commands before running the cmake configure/build steps. In my case that would simply calling the setvars.bat script. I wonder if and how other people managed to get this to work.
I had a similar problem. I ended up writing a Jython script to generate environment files to load with the env plugin. It worked but was too clunky. (I can give it to you if you want it.)
I decided to simply use the CMake plugin to generate solution and project files. I leave the “Make command” line empty. Then I use several MSBuild Build steps.
Hello, thank you for the plugin,
I using multi-configuration jobs on linux slave node with cmakebuilder plugin, but it doesn’t substitute axis value in this plugin (substituting environment variable works). Do you plan fixed it? tx.
Andrei
Hello, I use the plugin in a free-style software project and set “../common_install”, which means the CMAKE_INSTALL_PREFIX is set to a path “D:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\jobs\common_install”. But when install, the CMAKE_INSTALL_PREFIX is set to “D:\Program”, so I guess the path containing blank is not correctly processed in the plugin. Do you plan to fix it? Thank you!
Thank you for the great plugin, it was really easy to get it to work and do what we wanted. The only small problem is with the output it generates for the build step: Every line is followed by an empty line. The server runs on Win 7 x64 and uses VC++ 10.
$ cmake –build . –target Tests
Microsoft (R) Visual Studio Version 10.0.30319.1.
Copyright (C) Microsoft Corp. Alle Rechte vorbehalten.
1>—— Erstellen gestartet: Projekt: ZERO_CHECK, Konfiguration: Debug Win32 ——
1>Der Buildvorgang wurde am 2/05/2012 5:14:44 PM gestartet.
http://pastebin.com/J5QpEJ1X
Hello, I want to have a matrix project that compile different types of build, so I add a user defined axis build_type with values Debug and Release and then I put $build_type in other build type, but the variable does not expand. Any idea of how to resolve this ?
thanks in advance
>then I put $build_type in other build type
You mean you use $build_type in other projects? Check out the setting “Trigger parameterized build on other projects”, might help.
Nope, I juste have one project I want to compile with different build type I defined in a matrix user defined axis. I don’t want my project to launch others project.
Exactly where do you use the $build_type? I got it to work by using it in a “Windows batch command” build step as %build_type%. I think there are still bugs in Jenkins when it comes to matrix projects, and you have to work around them.
I use the $build_type in the “Other Build Type” field of the “CMake build” section. You say I could had a “Windows batch command” section before the “CMake build” section which set the build type of CMake ? but the build type will not be overwrited by “Cmake build” section ?
Check out my answer here, I think it might help you. I tried the CMake plugin too, but it didn’t work well enough, so I only use “Windows batch command”. http://stackoverflow.com/questions/10718067/jenkins-windows-cmake-multiple-build-types-debug-release
I tried the plugin and it works.
But if I use variables for parameter Source Directory the plugin do not recognise the path. Absolute paths are working.
(I have to store the sources outsite $Workspace for some SCM reasons.)
Thanks for providing the plugin. I’m trying to get Jenkins working with our CMake build and running into what seems to be a routine problem to solve. The build always fails with the following error:
CMake Error: The source directory “C:/Jenkins/workspace/TestProject/bin” does not appear to contain CMakeLists.txt.
Of course my /bin directory is empty, because I expect CMake to populate it. I have the following configuration:
Source directory:
Build directory: bin
Install directory:
Clean Build and Wipeout Install Dir are both checked.
Any help is appreciated. Thanks!
Hi,
I’m trying to use your plugin with VS2010 and I don’t know how to specify the vcvarsall into my cmake project. Is there a way to solve this problem ?
Thank you very much!
Olivier