logo标签列表

替代Autoconf和Autotools的选择？

cautotoolsautoconf
62
我是GNU Autotools （主要是Autoconf，偶尔使用Libtool）的经常用户。 我正在开发一个需要考虑可移植性的项目。 但是，我们团队中的其他成员不太熟悉m4语言。 我从四个人那里都收到了这样的邮件：this。

m4 is NOT lisp, dammit!

无论如何，也许有人可以推荐一些基于Python或PHP的东西？我正在处理更大树的C端; 我可以确定Python或PHP 5将出现，因为它们是先决条件。

11
熟悉m4并不重要。因为m4而反对autoconf就像因为编译器使用lex生成的词法分析器而反对C语言，而开发人员不理解lex一样荒谬。在使用autotools时，您可以在98%的时间内完全忽略m4。在剩下的2%中，您也可以忽略m4！通常，如果您发现自己遇到与m4相关的问题，那么这可能是因为您在做其他基本错误的事情。 - William Pursell
4
@WilliamPursell 在我提出这个问题后过了几年，我倾向于同意。但问题仍然存在——使用它很容易走上根本错误的道路。当你想要从configure获得真正细粒度的构建控制时，最终会遇到M4。除非我错过了什么？ - Tim Post
1
@TimPost 我曾经也遇到过类似的争论。没有人想学习M4（或者任何可以避免的东西）。这个项目变成了一个由bash和python脚本组成的组合，再加上一个丑陋的C++应用程序，主要只是使用C风格的宏。最终，在系统变得任意复杂（C++应用程序通过system(2)调用python和shell脚本）6个月后，我有权利将其砍掉，并用一个200行的M4脚本代替这个混乱。我永远不会接受“我们不想学习它”作为一个有效的借口。 - Cloud
9个回答
58

我冒着被踩的风险承认，很不幸地，没有真正的替代autotools。CMake、SCons、bjam都很好，但是当涉及到严肃的工作时……很明显autotools更胜一筹，不是因为CMake不能做同样的事情，而是因为用它做这件事情要困难得多。

例如，CMake这个最流行的autotools替代品有以下缺点：

  • 没有gettext的支持。当您需要管理大量翻译和已翻译的源代码时，这可能是一个真正的问题。
  • 没有卸载目标的支持。发现自己安装的程序无法卸载是非常不愉快的事情。
  • 不能自动构建共享库和静态库的两个版本。
  • 文档非常有限且质量差。

等等。

还有许多其他的问题。不幸的是，autotools没有真正高质量的替代品。另一方面，如果您在Windows上开发并且使用Visual Studio，则无法使用autotools，您需要选择提供此类工具的CMake。

5
你所说的都是真的！如果你在使用Windows/Linux x86/Mac OS X操作系统上遇到SCons和CMake，看起来比auto tools更简单。但是如果你遇到了一些不常见的平台，你可能会遇到很多问题... - gavenkoa
21
人们经常忽视 Autotools 为何用 m4 编写的原因。它使用 m4 编写，以便可以在 纯 shell 中生成配置脚本，从而可以针对任何 UNIX 平台。另一方面，CMake 可以针对任何有 CMake 的东西。现在，哪个更常见？CMake 还是 Bourne Shell？我倾向于说 Bourne Shell 更常见。也不是 Autoconf 的编写者的错，Windows 忽略了提供一个像样的 shell。 - alternative
1
我认为这是最好的答案。我经常使用autotools，有时确实很痛苦。但我总能完成任务，而且标准的autotools提供的configure和Makefile非常有用。我偶尔使用cmake，必须承认它更难使用（例如构建源代码），而且没有足够的在线资源可以快速掌握我使用autotools的技巧。 - Pavel Šimerda
即使 Bourne Shell 更有可能已经安装，但仍然需要下载“某些东西”才能让项目构建（至少是源代码，但很可能还有几个依赖项）。由于现在有大量的项目需要 CMake，所以很有可能 CMake 已经安装了。CMake 有它的怪癖和缺点，但我不认为“它不能直接从 shell 运行”是反对 CMake 的好理由。你仍然需要下载“某些东西”。 - Alexander
1
@gavenkoa，特别是当你想在CMake中掩盖Windows和类Unix系统之间的差异时，我发现这是一个问题。 - 0xC0000022L
39

我在使用SCons方面有不错的成功。它是用Python构建的，构建脚本实际上是Python脚本本身，这给予了很大的表达能力。以下摘自网站：

SCons是开源软件构建工具，也就是下一代构建工具。将SCons视为改进、跨平台替代经典的Make实用程序，集成类似于autoconf/automake和编译器缓存（例如ccache）的功能。简而言之，SCons是构建软件更轻松、更可靠、更快速的方法。

39

我听说过很多好的关于CMake的。它试图解决相同的问题。这里是维基百科的文章。

使用了很长时间，没有出现任何重大问题。 - Anonymous
我会建议同样的事情。之前我自己也问过同样的问题，得出的结论是CMake是正确的答案。 - Juliano
22
谢谢，看起来Cmake会完全满足我的需求。现在，如果我甚至轻声地提到“autoconf”，村民们就会拿着火炬和草叉出现在我的桌子前。 :| - Tim Post
19

有很多不同的替代Makefile生成器和构建系统：

还有其他可用的选项，但并非专门针对C/C++：

  • Premake
  • Ant（适用于Java）
  • Rake（适用于Ruby）
  • （肯定还有更多，我只是不知道所有的...）

但是，在列出这些选项之后，Autotools 有一个非常大的优点，即不需要任何其他依赖项。开发者只需生成一次配置脚本，而用户端不需要任何特殊要求，因为它是一个shell脚本。上面列出的工具在任何人能够构建源代码之前都必须被安装，它们甚至可能具有自己的依赖项。

1
一个配置脚本需要一个 sh 兼容的 shell，在 Windows 机器上这是一件特殊的事情。 - Caotic
7
如果在Windows上需要额外的软件，那又有什么意义呢？安装Python或某个Shell也没什么区别。 - raimue
这里有一个大列表，更多细节请参见Wikipedia Build Automation List。 - Mohamed Hamzaoui
@Caotic 我不知道2009年的情况如何，但我认为自几年前以来，由于GFW/git bash的普及，具有Bourne兼容性的shell已经不再是“Windows机器上的特殊东西”了。在我工作的地方，如果一个开发人员没有安装这样的东西，那对我来说会很惊讶。另一方面，使用Make/autotools可能需要安装MSYS2。 - kelvin
16
3
那个Makefile模板不支持自动依赖关系，这很好。 - alternative
“那就是pkg-config的作用？”http://hg.suckless.org/surf/file/tip/config.mk#l13 - hendry
3
我明白您的意思。我指的是从源代码生成的头文件之间的内部依赖关系，就像GCC所做的那样。一旦您弄清楚了如何做，这并不特别困难，但可能有点麻烦。 - alternative
2
像gcc -MM -MG -MT这样的东西？https://github.com/dontcallmedom/widlproc/blob/master/Makefile#L102 - hendry
2
没错，就是那样。 :) 将它添加到你的makefile模板中，确实可以使其变得更好。 - alternative
显示剩余3条评论
4
3

我已经研究了CMake，它看起来是一个很好的选择，除非你需要进行交叉编译。如果你正在进行本地编译，那么你应该尝试使用它。

1

如果您想从ANT或Maven构建C/C++软件，您可能会对terp感兴趣。它包括一个便携式的C++编译器任务，可以在许多平台上与许多C++编译器一起使用。

1
在Mozilla正在创建make的Python版本 - pymake - 这个版本很可能支持跨平台使用。
PyMake的真正作用只是修复在Windows上的GNU make中已经修复的错误。 - kirbyfan64sos
1
@kirbyfan64sos 很高兴 GNU make 团队没有浪费过去的六年。 - Pete Kirkham
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接