我尝试过Meson——遇到了一个问题，看了文档，然后在邮件列表上提问，但从未得到…

我在很多不同的架构和平台上编写过大量C语言代码：PDP、x86、ARM；Windows、BSD、Linux、VMS。我的项目从微小到巨大（数百万行代码）都有涉及。我从未需要过autoconf……它到底有什么用！？

libtool确实有它的用途：它会让普通的'make'生成shell脚本包装器作为输出，这在开发时可能有点用，但如果你想要一个真正的ELF文件，那就完全令人讨厌了。 所以你最终会运行'make install'，而你其实并不想安装，或者试图记住如何找到实际的ELF文件。然后你就会疑惑为什么'make install'看起来像是在构建东西而不是安装它们，然后你就会咒骂libtool。 稍微为它辩护一下，说服gcc（或者，天啊，早期的gcc之前的cc或ld或…）正确生成DSO的魔法咒语既复杂又依赖于平台。上次我试图不假思索地记住所有选项时，合理的默认值并不存在。

我不知道你怎么会觉得CMake比autoconf更差。至少它有一个声明式的方法，并且有很好的机制来重用通用逻辑。对于IDE/编辑器来说，它更容易处理。

> Bazel显然是一个糟糕的Google项目，如果你不够Google化的话就无法使用 我不太明白这是什么意思，听起来像是一堆无端的谣言。C++和Java在Bazel中是第一类语言。它在这些语言上运行得很好，然后是Go，接着你开始进入一些不稳定的领域

> 如果你添加了一个新的源文件，你必须重新运行 autoreconf 来重新生成你的 Makefile 你不需要这样做：automake 会为 `Makefile.am -> Makefile.in`（`automake`）和 `Makefile.in -> Makefile`（`config.status`）生成规则。你只需要编辑 `Makefile.am` 并运行 `make` 即可。 > 写 Makefile.am 比直接写 Makefile 真的更省事吗？那不是更简单吗？ 我认为不是。如果你想要正确地支持 DESTDIR，以及正确的依赖跟踪（编译时作为副作用生成依赖信息，这样你可以得到所有头文件，并且不会拖慢单次构建），以及支持所有标准的 Makefile 目标等等。 至于你问的「到底应该用哪个构建工具？」，我在关于可自举软件的背景下写过一篇更长的文章：http://jackkelly.name/blog/archives/2024/04/01/which_build_t... 看起来 autotools 仍然是其中一种…

我们应当直接编写 Makefiles。如果你想要更友善一些，可以让它包含一个 Makefile.inc 文件，并将所有用户配置内容放在那里。如果你想要更更友善一些，可以考虑接受针对流行发行版的 .inc 文件的 pull requests。

我认为 Cmake 的「杀手级应用」是它能够为 Visual Studio 和 Xcode 生成项目，这允许你使用这些产品提供的 Windows/Mac 特定工具链。在 Windows 上，它也比 Autotools 快很多，因为 NTFS 在处理大量小文件时性能很差。我同意它的语法很丑，但一旦克服了这一点，我发现它相当容易使用。最烦人的是弄清楚哪些 MSVC 标志对应我常用的 GCC 标志。 好奇一下，你的 C++ 开发流程是怎样的？你是否坚持使用文本编辑器而不是 IDE？