CMake是不是阻碍了C++的发展?

题主应该是碰到了学习路径的问题。先搞清楚cmake是干嘛用的。

比方说我要编译一个C++文件，我需要cpp文件，头文件，一大堆选项(比如禁用某个warning，启用某个宏，静态库还是动态库)，指定链接库文件名和路径等等，这些信息都必须通过命令行参数告诉编译器程序，如果缺失了那就会编译报错。这就导致我的编译命令会非常长，有时候甚至有几千几万个字符，仅仅是为了编译这一个文件。而且这些参数经常发生变化，比如我有时候要编译debug版本，有时候要编译release版本。再有就是项目文件一多，不同的文件需要不同的参数，导致整个项目的编译过程异常复杂。

为了解决这一个痛点，微软和linux提供了两种不同的解决思路。微软提供的是集成开发环境，反正大家都用我的windows系统嘛，那我就做一个visual studio(最早是visual c++)出来，带UI的，用一个project文件把所有的文件、配置信息、编译参数都记录下来，你只能按照我给你提供的功能定制project，你要自由度我也给你一定的自由度，比如pre-build，post-build脚本，反正足够你用。而linux提供了makefile，相当于一种脚本，可以在里面写调用什么编译器，编译哪些文件，加什么参数，写好了命令行敲一个make all，也很方便。不管哪种思路，核心还是一致的，就是提供一个编译配置文件，把要编译什么东西写清楚。

请注意调用make的过程分两步，第一步是解析makefile，然后把编译命令绑定到编译目标上(我们叫target)，然后当你确定了要编译哪个目标，才会真正去执行这些命令。比如一份代码，我们可以设置两个编译目标：android_app和desktop_app，需要安卓就"make android_app"。有点类似于visual studio里一个solution下的有两个project，虽然引用了同一份代码。所以这里就要搞清楚一点，我在makefile里面设置了一个变量AAA，只能对解析阶段起作用，影响的是命令的产生，如果你想给编译器传递一个变量，那你就得在对应位置加一条-DAAA。真正编译的过程只认那些组织好的命令参数，而不会管make的解析阶段的环境是什么。

那又有一个问题，就是当我需要跨平台的时候怎么办？我写一遍linux的makefile，还要再写一遍visual studio的project文件，尤其是项目非常大的时候参数很多很复杂，做起来就非常麻烦。这时候cmake的优势就有了，你只需要写一遍cmakelist.txt，我帮你产生对应的makefile或者vs的project文件，如果你要编译，我也可以帮你去调用make或者vs的命令行编译器。等于是一个make系统的产生器，他不直接调用编译器，只产生编译配置文件。

和make类似，cmake的变量只针对cmake解析过程中有用，对于产生的配置文件，除非你手动指定添加到哪里，否则是不会受到影响的。

本来想给题主建议点什么，想了想也没什么好的建议。cmake就是这样一个工具，和python，shell脚本之类的没啥大的区别。你在脚本里if (arguments[1] == "android_app"){...}也是一样的。多用用多接触点东西就好了。