本来vs是没有意见的，实在是vs 2017太大了，又不做windows下开发。从2020.2开始，clion原生支持makefile、cmake则很早就支持，这样对于makefile工程如pg就不再需要通过cmakefile调用makefile。
早期版本通过cmakefile调用makefile，可参考https://stackoverflow.com/questions/26918459/using-local-makefile-for-clion-instead-of-cmake
clion支持full remote development的概念，自动在本地目录和linux服务器目录间自动同步，使用远程的toolchains。比很多35后先本地vs搞好通用的，然后拷贝到linux上通过gdb调试或vs code远程调试不知道高多少倍（不好意思，在工作期间一两个月还没转过来的都被优化，先进的IDE从来都能提高生产力。如果你非说不影响工作效率，随意，如果别人都很快，你很慢，就不好意思），这事参考clion官方的full remote development一节手册配置即可。
clion有个做的不那么直接的功能是，已经直接支持attach to process，但是这个process不提供选择远程服务器上的进程（反之vs就直接提供，vs code天然走配置也支持）。对于单进程程序来说，clion的远程开发措措有余。如果是多进程开发，则通常主进程是网络监听器，子进程才是业务处理的地方，所以日常开发debug基本上子进程，clion的attach to process就不够了，以前总用vscode和vs配合，总觉得不方便。国庆研究了下，可以使用clion的gdb remote debug功能。
首先在linux服务器上安装gdb-server，yum install gdb-gdbserver-x86_64
在clion中，新建gdb remote debug，如下：
启动子进程，然后通过gdbserver attach到子进程。gdbserver :34567 --attach $(PID)
然后clion中启动debug，就可以看到进入断点了。
符号表是按需加载的，可以看到从远程加载到了e:\win\lib\debug\目录。从此，vscode和vs不再需要。
如果一直提示No symbol table is loaded. Use the "file" command ，则要看一下程序编译的时候是否没有包含O0 -g选项，默认gcc使用O2编译。
注：从idea 2020.1.1开始，也支持远程模式，这得感谢docker，使得某些要调用linux命令的开发调试大大简化。
