【CMake】使用(一)

1. • 环境

• ubuntu20.04系统下

2. • 初试

1. 建立文件目录等准备工作

mkdir -p/backup/cmake

cd /backup/cmake

mkdir t1

cd t1

在t1目录下建立main.c和CMakeLists.txt（注意文件名大小写）

2. 输入代码

main.c:

//main.c
#include<stdio.h>
int main()
{
    printf("Hello world from t1 Main!\n");
    return 0;
}

CMakeLists.txt:

PROJECT (HELLO)
SET(SRC_LIST main.c)
MESSAGE(STATUS "This is BINARY dir" ${HELLO_BINARY_DIR})
MESSAGE(STATUS "This is SOURCE dir" ${HELLO_SOURCE_DIR})
ADD_EXECUTABLE(hello ${SRC_LIST})

3. 测试：(以下图片为成功的结果)

cmake .

make

./hello

4. 相关解释

• PROJECT指令

PROJECT 指令的语法是
：PROJECT(projectname [CXX] [C] [Java])
我们可以用这个指令定义工程名称，并可指定工程支持的语言，支持的语言列表是可以忽略的， 默认情况表示支持所有语言。这个指令隐式的定义了两个 cmake 变量:<projectname>_BINARY_DIR 以及<projectname>_SOURCE_DIR，这里就是HELLO_BINARY_DIR 和 HELLO_SOURCE_DIR(所以 CMakeLists.txt 中两个 MESSAGE 指令可以直接使用了这两个变量)，因为采用的是内部编译，两个变量目前指的都是工程所在路径/backup/cmake/t1。

同时 cmake 系统也帮助我们预定义了 PROJECT_BINARY_DIR 和 PROJECT_SOURCE_DIR变量，他们的值分别跟 HELLO_BINARY_DIR 与 HELLO_SOURCE_DIR 一致。
为了统一起见，建议以后直接使用 PROJECT_BINARY_DIR，PROJECT_SOURCE_DIR，即 使修改了工程名称，也不会影响这两个变量。如果使用了<projectname>_SOURCE_DIR，修改工程名称后需要同时修改这些变量。

• SET指令

SET 指令的语法是：
SET(VAR [VALUE] [CACHE TYPE DOCSTRING [FORCE]])
比如我们用到的是SET(SRC_LIST main.c)，如果有多个源文件，也可以定义成：SET(SRC_LIST main.c t1.c t2.c)。

• MESSAGE指令

MESSAGE 指令的语法是：
MESSAGE([SEND_ERROR | STATUS | FATAL_ERROR] "message to display"...)
这个指令用于向终端输出用户定义的信息，包含了三种类型:
SEND_ERROR，产生错误，生成过程被跳过。
SATUS，输出前缀为—的信息。
FATAL_ERROR，立即终止所有 cmake 过程. 我们在这里使用的是 STATUS 信息输出，演示了由 PROJECT 指令定义的两个隐式变量HELLO_BINARY_DIR 和 HELLO_SOURCE_DIR。ADD_EXECUTABLE(hello ${SRC_LIST})定义了这个工程会生成一个文件名为 hello 的可执行文件，相关的源文件是 SRC_LIST 中 定义的源文件列表， 也可以直接写成ADD_EXECUTABLE(hello main.c)。

• ADD_EXECTABLE

语法：ADD_EXECUTABLE(hello ${SRC_LIST})
定义了这个工程会生成一个文件名为 hello 的可执行文件，相关的源文件是 SRC_LIST 中
定义的源文件列表， 本例中你也可以直接写成 ADD_EXECUTABLE(hello main.c)。

在本例我们使用了${}来引用变量，这是 cmake 的变量应用方式，但是，有一些例外，比
如在 IF 控制语句，变量是直接使用变量名引用，而不需要${}。如果使用了${}去应用变
量，其实 IF 会去判断名为${}所代表的值的变量，那当然是不存在的了。

本例也可以改写成一个最简化的 CMakeLists.txt：

PROJECT(HELLO)
ADD_EXECUTABLE(hello main.c)

当我们想要发布代码的时候，想要删除中间文件，但是当我们运行

 make distclean

是无效的。

官方给出的解释是：因为 CMakeLists.txt 可以执行脚本并通过脚本生成一些临时文件，但是却没有办法来跟 踪这些临时文件到底是哪些。因此，没有办法提供一个可靠的 make distclean 方案。同时，还有另外一个非常重要的提示，就是：我们刚才进行的是内部构建(in-sourcebuild)，而 cmake 强烈推荐的是外部构建(out-of-source build)。

对于 cmake，内部编译上面已经演示过了，它生成了一些无法自动删除的中间文件，所以，引出了我们对外部编译的探讨。

5. 外部编译

• 先清除 t1 目录中除 main.c CmakeLists.txt 之外的所有中间文件，最关键的是CMakeCache.txt。

• 在 t1 目录中建立 build 目录，当然你也可以在任何地方建立 build 目录，不一定必 须在工程目中。

• 进入 build 目录，运行 cmake ..(注意,..代表父目录，因为父目录存在我们需要的CMakeLists.txt，如果你在其他地方建立了 build 目录，需要运行 cmake <工程的全 路径>)，查看一下 build 目录，就会发现了生成了编译需要的 Makefile 以及其他的中间 文件。

cmake ..

• 运行 make 构建工程，就会在当前目录(build 目录)中获得目标文件 hello。

make

上述过程就是所谓的 out-of-source 外部编译，一个最大的好处是，对于原有的工程没有任何影响，所有动作全部发生在编译目录。通过这一点，也足以说服我们全部采用外部编译方式构建工程。

外部编译与内部编译文件目录对比：（显然外部编译看起来也更加简洁）

*部分参考CMake Practice--Cjacker