我有一个cmake示例项目，我想在Ubuntu 15.10上运行的Jenkins上构建 . 我安装了：
https://wiki.jenkins-ci.org/display/JENKINS/CMake+Plugin
并创建了两个构建步骤：
-
运行cmake以生成makefile
-
从构建目录运行 make all
我工作得很好：
[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的推荐方法吗？
目前我的cmake / Jenkins构建将在每次推动; 1）生成makefile，2）构建项目 .
我有点担心第一步1）生成makefile会占用构建时间，并且在每次推送时执行此步骤似乎并不是最佳选择 . 特别是因为我不希望经常更改 CMakeLists.txt 文件，但是当他们更改新生成的文件时，当然应该使用它们 .
以上方法是我必须习惯的常见做法还是我错过了什么？
2 回答
Yes, you can do it in one step.
例如，在我的Jenkins环境中，在构建Ubuntu作业时，我使用CMake插件进行整个编译，因为它允许多个构建工具调用 .
我在这篇文章底部的截图是作业中的CMake步骤（我使用Ninja而不是Unix Makefiles，但效果是一样的） .
我使用两个构建调用：
Blank - 相当于在shell中调用
ninja或make，Install - 相当于调用
DESTDIR=. ninja install.如果我想从makefile构建其他目标，我可以在此步骤中添加额外的调用 .
请注意，在屏幕截图中，配置中有一个空白调用 . 这将已经调用
make，并且由日志输出确认，实际上您正在编译项目两次，因为您在下一步中手动调用make all.您可以删除shell步骤，您的项目仍将构建 .
关于你关于最佳实践和重新生成CMake的问题，我建议您参考Jenkins Best Practices上的这篇文章：
请注意，我还在我的CMake步骤中检查“Clean Build”，以便整个CMake工作区被清除，并且每个构建都会从头开始生成项目 . 这可确保不存在由陈旧缓存变量等引起的问题 .
我的一个职位中的CMake步骤的屏幕截图：
我甚至不确定你是否需要这个插件 . AFAIR插件网页只有在您希望jenkins使用特定的cmake版本时才有用，或者您想要一个可能需要设置cmake变量的GUI . 我只是从命令行执行cmake .
对于问题的第二部分，如果更改CMakeLists.txt，Makefile将自动重新运行cmake，因此严格来说，不必每次都运行cmake . 但另一方面，cmake配置非常快，并且最有可能比编译花费更少的时间 .