除复杂度外，开发跨平台Autotools是否存在技术障碍？

你提到的这种工具，理论上确实能兼顾Autotools的“零额外依赖”和CMake的跨平台能力，但除了你说的复杂度高、CMake已占领市场之外，还有几个容易被忽略的原因：

• 平台碎片化带来的维护噩梦
  不同平台的shell环境差异远比想象中棘手：POSIX shell有bash、dash、ksh等多种实现，各自有细微的语法和特性差异；Windows的批处理和PowerShell是完全独立的两套语法，还要兼容不同版本的Windows系统（比如Win7的cmd和Win11的PowerShell 7）。要为每个平台写出可靠的依赖检查脚本，需要覆盖大量边缘情况，长期维护的成本会指数级飙升。另外，构建文件格式也五花八门——除了POSIX Makefile和VS解决方案，还有Xcode项目、Ninja文件等，要生成这些格式，得吃透每种格式的底层细节，这本身就是个庞大的工程。

• 用户习惯与生态锁定
  CMake已经形成了完整的生态闭环：几乎所有主流开源项目都在用它，IDE（VS、CLion、Xcode）、CI/CD工具都有完善的CMake集成，开发者和用户早就习惯了这套流程。没人愿意冒着风险切换到一个全新的工具，毕竟学习成本、适配成本都很高。再加上Autotools本身留给大家的“复杂、难用”印象，哪怕有跨平台版本，很多人也会直接抵触。

• 动态检查能力的天花板
  用shell/批处理做跨平台依赖检查，能力上限很低。比如在Windows上，用批处理检测编译器版本、系统SDK（比如.NET框架、Windows SDK）的存在和版本，难度远高于CMake的内置模块；而且脚本的错误处理、用户反馈很难做到像CMake那样清晰，出了问题用户根本不知道怎么排查。另外，复杂的构建逻辑（比如条件编译、自定义构建步骤）用脚本实现会非常繁琐，可读性和可维护性极差，远不如CMake的DSL直观。

• 分发与更新的麻烦
  要为所有支持的平台生成对应的脚本，项目分发包的体积会变大不说，每次修改构建逻辑，都要重新生成所有平台的脚本，这会额外增加开发者的工作量。而且脚本一旦分发出去，版本就固定了，如果用户的系统环境更新了，旧脚本可能无法适配；但CMake可以通过升级自身版本来解决这类问题，不需要开发者重新生成脚本。

内容的提问来源于stack exchange，提问作者lightspot21