qdbus模块_为什么会选择 make，cmake 之流来控制程序编译，而不是用现成的脚本语言，如 Python？...

首先SCONS就是Python的呀。

回到问题，我觉得是因为Python的Expressive Power太强大了……

先思考一个问题，为什么我们既然C/C++/Python/汇编这么强大的语言，到编译层面我们还要搞CMake/Make这种DSL？

原因在于编译这个问题的常用场景实在是非常有限，最常见的模式就那么几个，所以把这几个常见模式抽象出来变成Target/Executable/Library这些对象，然后用有限的关键字、参数制定成语法规则就形成了类似CMake/Makefile这样的DSL，这不比Python简单多了么

如果你去看看SCONS的编译怎么写的，其实本质上也就是是一堆Python上定义的Target/Executable之类的类，然后指定一下参数和名字。所以，不管用什么语言，其实本质上要解决的问题都是描述编译时各个组件的依赖。

但是为什么要搞CMake呢这种东西呢？就是因为它能把编译不关心的那些语言能力和细节从语法层面给排除掉，让DSL的能力仅限于解决特定问题。这样能够大大降低IDE支持的复杂度。

你想想，一个C++项目的编译链接过程，无非就是源文件、目标文件、可执行文件和库之间的映射和依赖关系。这些基本的功能完全可以通过非常少的语法来描述对不对，哪里用得到Python。

但是回到实际来看，如果项目稍微复杂一点，就会出现很多别的问题，比如数不胜数的编译选项、非C++项目的依赖、代码生成等等奇奇怪怪的需求。这时候就需要不停地去扩充DSL的语法库，语法描述页数不断增加……以至于你产生了为什么不用Python这样的问题。但是从我的经验来说，其实CMake20%的功能就已经能够cover80%的需求了。

我之前做过的一项工作就是把公司的SCONS编译系统完全替换成CMake，原因有几点相比CMake，没有发现哪个免费的IDE对SCONS支持得比较好

SCONS可以混着Python写(当然CMake也可以混着shell写)，加上项目早期大家写得很随意，所以整个构建系统难以维护

SCONS增量编译的时候依赖查询有点慢，而CMake可以输出成Ninja，一次增量编译能够快几十秒到几分钟

对于1来说，其实很大的原因就是SCONS的解析器相比于CMake略难写吧，因为你dependency的语法按照Python可以花式写，

对于2呢，其实这是工程管理的问题，用Python用CMake都会出现，我只是借这个机会重构规范了一下，定了一些强制标准，这样Clion、Eclipse都能正确解析，比如把一些老版本CMake的语法给禁用掉。

3其实不是SCONS的问题，要是足够流行的话应该有人也写。

我做下来的感觉就是，编译系统要要是没人好好维护，大家只管编译通过就行，那往往会乱成一坨屎。但凡有人花时间理一理，它其实可以很清晰。

对于你遇到的问题，find_package这个其实是历史遗留问题，因为Linux平台大家的环境千差万别，对于一个依赖他的位置有无数种可能性，所以需要用它来找依赖。我重构编译系统的时候，因为依赖系统包经常出现各种诡异的问题，所以索性所以第三方依赖全部从源代码进行构建，然后做缓存二进制文件，然后CMake导入，就不存在这种坑了。

总而言之，编译本质其实是一个特别简单的问题，就是源代码编译到目标文件再去链接。但是太多的技术细节会让人觉得非常复杂，其实不是，它只是繁琐而已，而且大部分繁琐的细节一般人接触不到。你抓住编译要解决的核心问题，再去看核心语法，然后按需翻阅手册，看看各种工程相关的设定，应该能很快上手。