CMake Builder Plugin Reloaded

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 :

Path to cmake executable

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.

CMake Builder Configuration Page

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

Advanced Configuration Page

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.

About these ads

66 Responses to CMake Builder Plugin Reloaded

  1. Ole says:

    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?

  2. Ole says:

    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.

    • volkerkaiser says:

      Thanks for your feedback! You’re right, “Finished: FAILURE” is not really chatty ;-) The next version will have some more meaningful error message.

    • volkerkaiser says:

      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.

  3. Ken says:

    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

  4. orzel says:

    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.

  5. Attet says:

    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\

  6. Xossarian says:

    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

  7. [...] previous OSLDs, we produced the cmake hudson plugin. In the corresponding blog entry, comments with bug reports began to pile up. They addressed issues with hudson master/slave setups. [...]

  8. [...] Builder Plugin in Master/Slave Setups The first versions of the cmake builder plugin were developed more or less only driven by our own needs. As people [...]

  9. Jordan says:

    Can this plugin be used without cmake to just kick off Make and record the output?

    • volkerkaiser says:

      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.

  10. Bruno says:

    Hello!

    Great work! Thank you a lot!

    Do you intend to use CTest results as Hudson input?

    Thanks.
    Regards.

    • volkerkaiser says:

      No, not in the near future. But some kind of integration of CTest would certainly be very nice.

      • Bruno says:

        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.

  11. Atte Timonen says:

    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

  12. James says:

    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)

    • volkerkaiser says:

      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.

  13. Dat Chu says:

    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.

  14. Chuck Lloyd says:

    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?

  15. Leo says:

    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!

  16. 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!

    • volkerkaiser says:

      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?

      • volkerkaiser says:

        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

  17. John Weald says:

    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.

  18. Leo says:

    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

    • Benjamin says:

      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.

  19. packadal says:

    Hi, I had the exact same problem (nullpointerexception) and this fixed it, thanks a lot :)

  20. Eric Herniou says:

    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

    • volkerkaiser says:

      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.

      • Eric Herniou says:

        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

  21. Leo says:

    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

    • volkerkaiser says:

      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.

  22. friso says:

    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)

  23. friso says:

    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.

  24. Chuck Lloyd says:

    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

    • Hugo Koblmueller says:

      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?

  25. Sagar says:

    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

  26. celeblung says:

    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?

  27. Michael says:

    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?

    • volkerkaiser says:

      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?

      • Michael says:

        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.

      • Chuck Lloyd says:

        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.

  28. andrei says:

    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

  29. [...] Check out my post introducing the newest version of the [...]

  30. lance says:

    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!

  31. Andreas Haferburg says:

    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.

  32. paul bedaride says:

    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

  33. Andreas Haferburg says:

    >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.

  34. paul bedaride says:

    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.

    • Andreas Haferburg says:

      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.

  35. Th. Thielemann says:

    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.)

  36. kohanz says:

    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!

  37. MelbOliv says:

    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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 79 other followers

%d bloggers like this: