一、make && Makefile
在相对比较大的项目中,项目通常会被模块化,使用make和makefile有助于简明的记录各个模块之间的复杂引用关系;如此之多的源文件,如果每次编译都要去敲gcc指定源文件和头文件以及链接库进行编译的确是个灾难;针对上面的问题,make应运而生。make根据makefile中定义的编译方式进行自动化的、定制化的编译,且能灵活地只对makefile中上次修改的部分进行重编译。
二、Cmake && CMakeLists
对于一个大工程来说,编写makefile是非常复杂的,于是有人设想能否有一种工具能够在读入所有源文件之后自动化的生成makefile?Cmake因此产生。但是cmake本身也是有标准的,需要开发人员编写cmakelists去生成makefile。
如图所示:
三、Clion远程编译和调试
0、本地编译调试
1、ssh远程编译调试
步骤一
导入clion项目,此过程会自动新建cmakelists
步骤二
配置远程地址和本地项目同步到远程的映射地址
CLion -> Preference -> ToolChains && Deployment
步骤三
clion原生的cmakelists是有问题的,会导致之后的make失败,而原生直接make却是可以的,所以这边需要修改下cmakelists
原生的是这样的:
1 | cmake_minimum_required(VERSION 3.14) |
修改以后:
1 | cmake_minimum_required(VERSION 3.14) |
add_custom_target可以在编译时动态指定命令,以这种模式引用原生的makefile生成makefile,这边将Linux上主目录下make编译后生成的netstat复制到cmake-build-debug目录下,之后debug的时候指定可执行文件就可以进行调试。
步骤四
配置调试选项,远端的编译目录需要有可执行文件
2、gdbserver远程调试
步骤一
在远程机(Linux)上首先进行make编译,之后将编译后的结果用gdbserver挂载在指定端口
步骤二
宿主机(Mac)上配置debug选项,指定gdb模式进行远程调试
需要注意的是path mappings这边需要将本地源码目录和远端的编译(可执行文件)目录对应起来,否则无法进行调试。
四、总结
花了大半天时间搞远程调试也是醉了,功力还是不到家,继续学习。记录下这边总结的几个点。
- gdbserver相对来说比ssh远程编译调试要方便(不用写cmakelists)
- 这篇文章中ssh远程编译那块有点问题后续看能否优化(不应该这麻烦,cmakelists应该可以写成直接在cmake-build-debug目录中生成netstat)
- clion动调对内存、寄存器等支持不太好,主要还是对代码层变量的显示修改等
- 初步了解cmake、make、makefile、cmakelists的概念,后续如果有需求可以深入学习