Qt 的make系统也挺坎坷的,qmake用了很多年了，设计比较简陋，qmake不是个脚本语言，也不是像json xml这种有schema的标记语言，就是个简单的配置选项，很难再继续扩展，qmake只用于Qt没有其它生态。
后来Qt 发起了qbs，希望基于Javascript语法做一套make系统，但是这个项目没成功
对于Qt这个规模的项目，剩下的选择就不多了，必须功能强大完整，必须跨平台，必须有成熟的生态，基本只有cmake可以选了。
cmake基本用过的人都不会觉得它有多好，其它make系统，比cmake使用体验好的没有cmake功能多，功能多的没有cmake生态完善，总之全面超越cmake的还没有出现。
顺便推荐下 xmake，功能已经很接近cmake了，个别能力甚至超越cmake，使用体验更友好，只是生态还需要时间去建设。
CMake is the build system for Qt 6
Qt and CMake: The Past, the Present and the Future
可以肯定的是为了支撑Qt EVERYWHERE 的愿景，找到一个跨平台的构建工具已经伤透了开发团队的脑筋。采用CMake应该是理智而无奈的选择。
首先，推动这个想法的最大需求，就是编译Qt本身的复杂性。几个文章主要讨论的是编译Qt库不用qmake而用cmake。以前用configure脚本自举生成qmake的情况没有了。这主要影响到与Qt深层代码交互的第三方扩展库的调整，这些库不能用qmake编译了。这侧面反应了没有虚拟机的C++跨平台是多么难的事情。要"到处都跑Qt"，面对的架构，平台千差万别，其中的工作量已经超越了团队的驾驭能力，或者透支了公司的运行成本。
其次，这个行为可能不小心直接决定了qtcreator的生死，立此文为据。目前qtcreator作为官方IDE，对CMake的自动化支持真的需要好好完善。如果纯Qt工程，pro文件的可读性，精炼程度，和IDE自动化操作能力暂时远胜于CMake的txt。一种可能，如果qtcreator把cmake自动化做活了，就可能跳出Qt飞得更高，成为一种新的的存在。另一种可能，如果不好好完善，放任现状让用户加个文件也要手动改txt，那它存在的必要就大打折扣，作为官方IDE就很尬了。
最后，感觉Qt这些年走过来真不容易。不知道其财政状况，但放弃qbs，自裁qmake，有可能是无力维持这么多的工具链。QML搞这么多年，有点起色但是人家硬件水平上去了，网页应用起来了。手机移动端，干不过原生的，有点鸡肋。Qt最大的价值是为开发桌面工业应用提供可靠的C++/C环境。有点过分的开玩笑: 如果没有Qt，C++就不再完整，Qt在C++陷入学院派的泛型综合症和固执的迭代器强迫症时，硬是凭着一己之力找回了烟火气。
CMake已经几乎是通用的标准了。
先说下CMake缺点，语法反人类，官方文档一坨屎。
但问题是这玩意解决了很多c++构建过程中的痛点，举几个例子：
1.不依赖java，python之类的环境，想移植就搞他自己就行了而不是带一大堆重量级亲戚。
2.解决了如何引入和检查第三方库的问题。大多数库都有cmake模块，没有的也给你提供了一堆用来检索库的工具函数。 3.解决了导处编译的时候的各种环境不一致导致的坑爹问题。换一台机器只要你环境变量配置对了或者库安装到系统默认位置的话啥都不用改直接就能用。
3.对编译工具链支持的相当广泛，msvc，sdcc，gcc，clang等大量编译工具都有原生支持，对gnu make，nmake，msbuild，ninja等make工具也有很广泛的支持。
4.提供常见os的辅助打包工具，你可以很方便的生成主流linux发行版，windows，mac的安装包。
5.内置自动测试框架。
6.便于扩展，你可以自己在CMakeLists.txt里面加上一些其他奇奇怪怪的功能，比如自动处理git依赖。
等等 这玩意就是做的比它人性化的生态比不上它，生态比它好的功能没它强最终被慢慢取代（说的就是autoconf），最终成了现在这样子。
Qt5发布前，社区就qmake和cmake展开或激烈讨论，共识就是需要换掉qmake，但官方认为cmake不怎么好，后来在Qt5弄了个qbs，以期待取代qmake。后来因为生态问题，砍掉qbs全面转向cmake
本质上，qmake语法太简单了，一个复杂工程需要一大堆的.pro/.pri/.prf/.prl文件，最后像天书一样。另外qmake很难维护.
