CMake，C ++和Jenkins/连续集成 [英] CMake, C++ and Jenkins/Continuous integration
问题描述
我有一个cmake示例项目，我想在Ubuntu 15.10上运行的Jenkins上构建该项目.我已经安装:
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 +插件
并创建了两个构建步骤:
And created two build steps:
- 运行cmake生成生成文件
- 从构建目录运行全部构建
我工作正常:
[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
但这是在CI/Jenkins设置中使用cmake的推荐方法吗?
But is this the recommended approach for using cmake in a CI/Jenkins setup?
当前，我的cmake/Jenkins构建将在每次推送时进行； 1)生成makefile，2)生成项目.
Currently my cmake/Jenkins build will on each push; 1) generate the makefiles, 2) build the project.
我有点担心第一步(1)生成makefile会占用构建时间，并且每次推送时执行此步骤似乎都不是最佳选择.尤其是因为我不希望经常更改 CMakeLists.txt 文件，但是当它们更改时，当然应该使用新生成的文件.
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 new 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?
推荐答案
是的，您可以一步完成.
例如，在我的Jenkins环境中，在构建Ubuntu作业时，我使用CMake插件进行整个编译，因为它允许多次构建工具调用.
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.
我在这篇文章底部的屏幕快照是工作中的CMake步骤(我使用Ninja而不是Unix Makefiles，但是效果是相同的).
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).
我使用两个构建调用:
- 空白-等同于在外壳中调用
ninja或make - 安装-等同于调用
DESTDIR=. ninja install.
- Blank - equivalent to calling
ninjaormakein a shell, - Install - equivalent to calling
DESTDIR=. ninja install.
如果我想从makefile中构建其他目标，则可以在此步骤中添加额外的调用.
If I wanted to build additional targets from the makefiles, I could just add extra invocations to this step.
请注意，在屏幕截图中，您的配置中有一个空白的调用.这已经在调用make了，并且正如日志输出所确认的那样，实际上是在两次编译项目，因为在接下来的步骤中手动调用了make all.
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.
您可以删除Shell步骤，并且您的项目仍将构建.
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:
为了确保内部版本可复制，该内部版本必须是完整的内部版本，它是完全从Source Code Control构建的.这种做法还意味着必须将所有代码(包括第三方jar，构建脚本，发行说明等)检入Source Code Control.
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.
请注意，我还在CMake步骤中选中了清理构建"，以便清除整个CMake工作区，并为每个构建从头开始生成项目.这样可以确保不会出现由过时的缓存变量等引起的问题.
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.
我的一项工作中的CMake步骤的屏幕截图:
Screenshot of a CMake step in one of my jobs:
这篇关于CMake，C ++和Jenkins/连续集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
