据说目前已经有更为现代化的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++文件.
