在做算法部署的过程中,我们一般都是用C++开发,主要原因是C++的高效性,而构建维护一个大型C++工程的过程中,如何管理不同子模块之间的依赖、外部依赖库、头文件和源文件如何隔离、编译的时候又该如何相互依赖这些问题,直接用Makefile实现是比较麻烦的。这个时候,CMake的优势就显现出来了,简洁的命令大大简化了项目构建过程,而且其跨平台特性也方便了不同部署平台间的迁移。这里我想把工作这一年来,在实践过程中学到的CMake用法做个总结。这里会参考一篇在知乎写的非常不错的文章,但这里我只记录我认为比较重要的部分,从来不会用到的功能不去深究,毕竟只是个工具,够用就行。
一、CMake构建编译原理概述
- 单个cpp文件可以通过gcc直接编译生成可执行文件,但当项目很大时,这种方式便不再适用,我们需要写Makefile或者CMake。
- CMake构建C++工程其实是充当一个生成Makefile的媒介,以往直接写Makefile也是可以的,但是当工程越来越复杂的时候,Makefile就不那么好写了,目前也不要求自己学会写Makefile了;
- cpp工程一般由头文件目录、源文件目录和第三方库目录三大块代码内容组成,CMake一般会在每个模块文件夹下都建立一个CMakelists.txt文件,而在最顶层的源文件目录下,会建立一个总的CMakelists.txt用于控制整个cmake流程,然后通过add_subdirectory()命令递归的访问每个模块目录执行cmake,最后在build目录下生成一个总的makefile用于编译源码。头文件目录存放最终SDK提供出去需要的头文件、以及一些需要源文件目录访问的接口类定义头文件,源文件下的代码存放实现类,大致如此。CMake中需要配置每个模块编译时头文件需要从哪里找、还有链接的时候库文件需要从哪里找。
- gcc编译生成的目标文件分为三类,可执行文件、动态库和静态库。其中可执行文件在链接过程中会链接一些系统c运行时库等,需保证可执行文件对应的源码中main函数是存在的,不然会链接失败。动态库和静态库可以朴素的理解为就是一系列的cpp文件打包而成的,cpp文件中会定义一些类和函数可供调用,此外还有一些全局变量。
二、CMake用法总结
2.1 使用与设置系统环境变量与系统信息
| $ENV{Name} |
| set(ENV{Name} value) |
| UNIX |
| WIN32 |
2.2 CMake预定义变量
| PROJECT_SOURCE_DIR # 工程的根目录,即根CMakefiles.txt文件所在目录 |
| PROJECT_BINARY_DIR # 运行 cmake 命令的目录,通常是 ${PROJECT_SOURCE_DIR}/build |
| CMAKE_CURRENT_SOURCE_DIR # 当前处理的 CMakeLists.txt 所在的路径 |
| CMAKE_CURRENT_BINARY_DIR # target(包括可执行文件与库文件) 编译目录 |
| CMAKE_CURRENT_LIST_DIR # CMakeLists.txt 的完整路径 |
| CMAKE_MODULE_PATH # 自己的 cmake 模块所在的路径,SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake) |
| EXECUTABLE_OUTPUT_PATH # 目标二进制可执行文件的存放位置 |
| LIBRARY_OUTPUT_PATH # 目标链接库文件的存放位置 |
| |
| CMAKE_CXX_FLAGS # 设置 C++ 编译选项,如优化等级、c++版本等 |
2.3 常用命令
| cmake_minimum_required(VERSION3.20.1) |
| project(demo) |
| option(<variable> "<help_text>" [value]) |
| |
| add_executable(demo demo.cpp) |
| add_library(common SHARED util.cpp) |
| set_property(TARGET common PROPERTY POSITION_INDEPENDENT_CODE ON) |
| set(SRC_LIST main.cpp) # 设置变量 |
| list(APPEND SRC_LIST test.cpp) #追加文件到变量list |
| list(REMOVE_ITEM SRC_LIST main.cpp) #从变量列表中移除文件 |
| if (expression) |
| |
| |
| if (variable LESS number) |
| if (string LESS number) |
| if (variable GREATER number) |
| if (string GREATER number) |
| if (variable EQUAL number) |
| if (string EQUAL number) |
| |
| |
| if (variable STRLESS string) |
| if (string STRLESS string) |
| if (variable STRGREATER string) |
| if (string STRGREATER string) |
| if (variable STREQUAL string) |
| if (string STREQUAL string) |
| #while 循环 |
| while(condition) |
| ... |
| endwhile() |
| |
| # for循环 |
| # start 表示起始数,stop 表示终止数,step 表示步长 |
| foreach(loop_var RANGE start stop [step]) |
| ... |
| endforeach(loop_var) |
| |
| function(_foo) |
| foreach(arg IN LISTS ARGN) |
| message(STATUS "this in function is ${arg}") |
| endforeach() |
| endfunction() |
| |
| _foo(a b c) |
| |
| |
| |
| aux_source_directory(dir VAR) 将目录下所有的源代码文件列表存储在一个变量中 |
| file(GLOB SRC_LIST "*.cpp" "protocol/*.cpp") |
| file(GLOB_RECURSE SRC_LIST "*.cpp") |
| add_library(demo SHARED ${SRC_LIST} ${SRC_PROTOCOL_LIST}) |
| find_library(VAR name path) #查找指定名称的库文件,并将路径存储到VAR中,其中path是库文件所在目录。 |
| find_package(<Name>) # 通过寻找 Find<name>.cmake文件引入其他包,具体搜索路径依次为:1. $中的所有目录;2. 再查看CMake自己的模块目录 /share/cmake-x.y/Modules/,通过$CMAKE_ROOT可查看;3. 在~/.cmake/packages/或/usr/local/share/中的各个包目录中查找<库名字的大写>Config.cmake 或者 <库名字的小写>-config.cmake。 |
| 找到上述.cmake文件后,就会定义下述几个变量: |
| <NAME>_FOUND #判断查找是否成功 |
| <NAME>_INCLUDE_DIRS or <NAME>_INCLUDES #package的头文件包含目录 |
| <NAME>_LIBRARIES or <NAME>_LIBRARIES or <NAME>_LIBS # package的库目录 |
| 然后就可以使用该库了。 |
- 设置包含目录
只有将包含目录设置了,在源文件中的include才能正确索引到头文件
| include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include) |
- 添加子目录并用CMake构建子目录
CMake一个很好的功能就是,可以在个子目录设置单独的CMakelists.txt,然后再上一层的Cmakelists.txt中添加该子目录即可,例如:
| |
| add_subdirectory(source_dir [binary_dir] [EXCLUDE_FROM_ALL]) |
| link_directories(${CMAKE_CURRENT_SOURCE_DIR}/libs) |
| target_link_libraries(demo libface.a) |
- 打印log信息
有些时候我们需要在终端打印某个变量以确定是否符合预期
| message(STATUS ${PROJECT_SOURCE_DIR}"this is warnning message") |
| message(WARNING "this is warnning message") |
| message(FATAL_ERROR"this is error message") |
| |
| file({COPY | INSTALL} <file>... DESTINATION <dir> [...]) |
| |
| file(MAKE_DIRECTORY [<dir>...]) |
三、编译示例
假如有如下结构的示例工程:
| | |
| | |
| | | |
| | ` |
| | |
| | |
| | | |
| | ` |
| | |
| | | |
| | | |
| | | | |
| | | | |
| | | | ` |
| | | | |
| | | | ` |
| | ` |
| | | | |
| | | | |
| | | | ` |
| | | ` |
| | | ` |
| | |- test # 一般为单元测试代码 |
| | | |
| | ` |
| | ` |
| | |
| | |
-
一般的CPP工程都按照上述结构组织,源码只存放在source和include文件夹中,其中include存放公共头文件,一般是一些需要提供出去的虚接口类;source下也会按照模块分别有每个模块的.h头文件和.cpp源文件,分别存放class声明和成员函数实现。此外还有单元测试代码,长期看单元测试是十分必要的。C++的STL我们可以直接使用,但第三方库需要引入才能使用,较小的库可以随工程放入单独的文件夹内,例如libs或者3rdparty文件夹下可以将opencv放进去,但像cuda这种很大的库,一般还是会从系统安装目录动态链接过来。
-
上述工程目录中的CMake脚本的工作逻辑是:先shell命令创建build目录,然后在cd到build目录后执行cmake ..,这样就搜索到了根目录下的Cmakelists.txt,然后按顺序执行其中的命令,这个cmake脚本中需要做的工作包括:①项目名称设定、option开关设定、CMAKE_CXX_FLAGS设定;②外部头文件包含目录设定;③第三方库文件引入(opencv和cuda);④添加需要编译的子目录。然后递归执行子目录中的cmake流程。
-
cmake过程中一般比较容易出现的问题是:库找不到。一般都是路径不对或者相关库未安装。
make过程中一般出现的问题是:头文件找不到、重定义、链接失败等。这些问题也需要返回到cmake脚本中修复。
CMakelists.txt示例:
本来是要在windows的SWL上写一个demo的,手欠先升级到了SWL2,结果之前的子系统登不进去了,又得重新配置ubuntu编译环境。样例这块就先不实践了。后续写c++项目的时候,再对其中的CMake做一次解析。
四、小结
这次花了一天时间对cmake的相关内容回顾和总结了一下,但工具不用很快就忘记了,这类东西最好还是在工作实践过程主动去尝试去思考,平时一个工程如果架构构建完成后,cmakelist是很少去动的,所以从头写的机会比较少。那么就要在看到别人的cmakelists.txt的时候,多想想为什么他这样写,学习别人是如何写出简洁的cmakelists.txt文件的。cmake的思路其实和编译原理是相辅相成的,学会cmake对我们理解项目架构、解决库依赖问题很有帮助。
参考:
- https://zhuanlan.zhihu.com/p/470681241