CMake, C++ and Jenkins/Continuous integration
Solution 1
Yes, you can do it in one step.
For example, in my Jenkins environment, when building the Ubuntu jobs I use the CMake plugin for the whole compilation, as it allows multiple build tool invocations.
My screenshot at the bottom of this post is of a CMake step in a job (I use Ninja instead of Unix Makefiles, but the effect is the same).
I use two build invocations:
-
Blank - equivalent to calling
ninja
ormake
in a shell, -
Install - equivalent to calling
DESTDIR=. ninja install
.
If I wanted to build additional targets from the makefiles, I could just add extra invocations to this step.
Note that in your screenshot you have a blank invocation in the configuration. This will already be calling make
, and as confirmed by your log output, you are in fact compiling your project twice, because of your manual call to make all
in the following step.
You can remove your shell step and your project will still build.
Regarding your question on best practices and regenerating CMake, I refer you to this article on Jenkins Best Practices where it states:
To ensure a build can be reproducible, the build must be a clean build, which is built fully from Source Code Control. This practice also implies that all code including third-party jars, build scripts, release notes, etc. must be checked into Source Code Control.
Note that I also check "Clean Build" in my CMake step, so that the entire CMake workspace is wiped out and the project is generated from scratch for every build. This ensures there are no issues caused by stale cache variables, etc.
Screenshot of a CMake step in one of my jobs:
Solution 2
I am not even sure you need this plugin. AFAIR the plugin webpage it is only useful if you want Jenkins to use a specific CMake version, or you want a GUI for which CMake variables you might want to set. I just execute CMake from the command line.
For your second part of the question, If you change CMakeLists.txt, the Makefile will automatically rerun CMake, so strictly speaking it is not necessary to run CMake each time. But on the other side, CMake configuring is quite fast and most likely takes less time than compiling.
Related videos on Youtube
u123
Updated on September 15, 2022Comments
-
u123 over 1 year
I have a CMake sample project that I would like to build on Jenkins running on Ubuntu 15.10. I have installed:
https://wiki.jenkins-ci.org/display/JENKINS/CMake+Plugin
And created two build steps:
- Run CMake to generate makefiles
- Run make all from the build dir
It works fine:
[build] $ cmake -G "Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug /var/lib/jenkins/workspace/cmake-test/cmake-gtest/src -- Configuring done -- Generating done -- Build files have been written to: /var/lib/jenkins/workspace/cmake-test/cmake-gtest/build [build] $ /usr/bin/make [ 4%] Built target libfoo [ 9%] Built target libbar [ 14%] Built target myApp [ 52%] Built target gmock [ 90%] Built target gtest [100%] Built target testfoo [cmake-test] $ /bin/sh -xe /tmp/hudson1792271459427590561.sh + cd cmake-gtest/build + make all [ 4%] Built target libfoo [ 9%] Built target libbar [ 14%] Built target myApp [ 52%] Built target gmock [ 90%] Built target gtest [100%] Built target testfoo Finished: SUCCESS
But is this the recommended approach for using CMake in a CI/Jenkins setup?
Currently, my CMake/Jenkins build will on each push; 1) generate the makefiles, 2) build the project.
I am a bit worried that the first step 1) generate makefiles would eat up build time and it does not really seem optimal to do this step on each push. Especially since I would not expect to change CMakeLists.txt files that often, but when they change newly generated files should, of course, be used.
Is the above approach common practices that I just have to get used to or have I missed something?
-
gsamaras over 5 yearsThis is exactly what I was thinking, but I am not sure if it's correct, so no upvote. Should we use a plugin when we want to to do CI with a C++ project or just call
make
or whatever from the command line? It would be nice if you could expand on that with some references.