关于CMAKE构建C/C++遇到的问题汇总
据说目前已经有更为现代化的cmake,先不说现代化的cmake如何如何.本文记录是目前工作后又遇到的常规cmake的问题。不确定是否高版本的cmake已经解决了一些自身的问题.本文只做记录.
cmake 持续记录
- CMakeLists.txt 这个
文件名
在构建的时候是固定的,除非使用include
包含其他的以.cmake后缀结尾的文件,比如工具链文件. - 一般会在CMakeLists.txt这个文件下创建build目录,在build目录下执行cmake… 然后
make clean all -j8
,若是不指定输出库和可执行文件的目录,则默认会在build下的对应目录(一般是子目录)
下生生成. - 若是修改了CMakeLists.txt,不需要重新执行cmake … 直接make 会默认去执行cmake … (从中看出cmake是比较
智能
的). - 通常,当项目编译很慢的时候,执行make -j8 (
-j8 表示使用多线程
),如果发生报错,再执行make(这个时候不加-j xxx
则能快速定位到错误所在. - cmake的子目录能共享父目录里面的变量,父目录不能直接共享子目录里面的变量.
- cmake链接到库的问题: 若是由当前的工程生成的库(无论是
静态库还是动态库
,可以直接通过库名
进行链接
,若是使用外部非当前工程生成的库,需要指定外部库的路径
,再使用其外部库的库名
(去掉前缀和后缀
)链接.或者是直接使用外部库的绝对路径链接,再或者是使用find_library
查找一番,.在交叉编译时,在link到外部库时,我建议还是使用绝对路径(这是一种保险的做法
,一是为了区分外部库和当前生成的库,二是因为有时候虽然指定了外部库的link路径,然后直接使用库名链接却依然找不到库(无论有没有删除cmake的缓存
). - 使用
find_library
赋值的变量会存在缓存,需要删除cmake的cache文件,以免产生影响.
制作库持续记录.
- 解决命名冲突,虽然它一直是个诟病的地方,不要使用全局变量,C++变量都用命名空间来进行管理,C的话能不能用结构体来代替.
- 规范的用一个头文件进行声明,表示库里的函数和命名空间.
- C++使用C编译而来的库,extern "C {头文件} 。因为
C++和C的编译方式不一样
,比如函数名字,经常会因为使用外部库,(问题还在于你不问问根本不知道是C的库还是C++的库),经常因为这个问题导致找不到函数符号
.如果是C用C++的话,还不如直接把C文件改成C++文件
.
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· NetPad:一个.NET开源、跨平台的C#编辑器