为什么用linux开发工具,linux-当我们只编写自己的makefile时，为什么要使用诸如Autotools之类的构建工具？...

linux-当我们只编写自己的makefile时，为什么要使用诸如Autotools之类的构建工具？

最近，我将开发环境从Windows切换到Linux。 到目前为止，我只使用Visual Studio进行C ++开发，所以许多概念(例如make和Autotools)对我来说都是新的。 我已经阅读了GNU makefile文档，并对它有了一个大概的了解。 但是我对Autotools感到困惑。

据我所知，makefile用于简化构建过程。

为什么我们仅需要Automakes之类的工具来创建Makefile？ 由于所有人都知道如何创建makefile，因此我没有真正使用Autotools。

标准是什么？ 我们是否需要使用这样的工具，还是只使用手写的makefile？

8个解决方案

79 votes

您在这里谈论的是两个独立但相互交织的事物：

自动工具

GNU编码标准

在Autotools中，您有几个项目：

自动配置

自动制作

Libtool

让我们分别看看每个。

自动配置

Autoconf可以轻松地扫描现有树以找到其依赖项，并创建一个配置脚本，该脚本将在几乎任何类型的shell下运行。 configure脚本允许用户控制构建行为(即config.h、HAVE_LIBPTHREAD、--prefix、--sysconfdir等)，并进行检查以确保系统可以编译程序。

Configure会生成config.h文件(来自模板)，程序可以包含该文件来解决可移植性问题。 例如，如果未定义HAVE_LIBPTHREAD，请改用叉子。

我个人在许多项目上使用Autoconf。 通常需要一些时间才能习惯m4。 但是，它确实可以节省时间。

您可以使makefile继承一些配置查找的值，而无需使用automake。

自动制作

通过提供一个简短的模板来描述将要构建哪些程序以及需要链接哪些对象来构建它们，可以自动创建符合GNU编码标准的Makefile。 这包括依赖项处理和所有必需的GNU目标。

有些人发现这更容易。 我更喜欢编写自己的makefile。

Libtool

Libtool是一个非常酷的工具，用于简化任何类Unix系统上共享库的构建和安装。 有时我用它； 其他时候(尤其是在构建静态链接对象时)，我会手动完成。

还有其他选项，请参见StackOverflow问题Autoconf和Autotools的替代方案？

构建自动化和GNU编码标准

简而言之，如果您将代码发布给大众，那么您确实应该使用某种便携式构建配置系统。 您使用什么取决于您。 众所周知，GNU软件几乎可以在任何东西上构建和运行。 但是，您可能不需要遵守这些(有时甚至是非常古怪的)标准。

如果有的话，如果您正在为POSIX系统编写软件，我建议您尝试一下Autoconf。 仅仅因为Autotools产生了与GNU标准兼容的构建环境的一部分，并不意味着您必须遵循那些标准(很多不是！):)还有很多其他选择。

编辑

不要担心m4 :)总是有Autoconf宏存档。 大量的例子，或下降支票。 自己编写或使用经过测试的内容。 Autoconf经常与Automake混淆。 他们是两件事。

Tim Post answered 2020-01-16T04:28:57Z

31 votes

首先，正如tinkertim已经指出的那样，Autotools并不是一个不透明的构建系统，而是一个松散耦合的工具链。 让我在Autoconf和Automake上添加一些想法：

Autoconf是一种配置系统，它基于应该在所有平台上都可以使用的功能检查来创建配置脚本。 在其存在的15年中，许多系统知识已进入其m4宏数据库。 一方面，我认为后者是自动工具尚未被其他工具取代的主要原因。 另一方面，当目标平台更加异构并且必须支持Linux，AIX，HP-UX，SunOS等时，Autoconf变得更为重要。 如果您只想支持最新的Linux发行版和Intel兼容的处理器，我真的看不出它的意义。

Automake是GNU Make的抽象层，并充当更简单模板的Makefile生成器。 最终，许多项目摆脱了Automake的抽象，转而手动编写Makefile，因为您失去了对Makefile的控制权，并且可能不需要所有混淆Makefile的罐装构建目标。

现在介绍替代方案(我强烈建议根据您的要求替代Autotools)：

CMake最显着的成就是在KDE中取代了AutoTools。 如果您想拥有无m4特质的类似于Autoconf的功能，那么它可能是最接近的。 它为桌面带来了Windows支持，并已证明适用于大型项目。 我对CMake的看法是，它仍然是一个Makefile生成器(至少在Linux上如此)，它具有所有内在的问题(例如Makefile调试，时间戳签名，隐式依赖顺序)。

SCons是用Python编写的Make替代品。 它使用Python脚本作为构建控制文件，允许使用非常复杂的技术。 不幸的是，它的配置系统不能与Autoconf相提并论。 当适应特定要求比遵循常规更为重要时，SCons通常用于内部开发。

如果您真的想坚持使用Autotools，我强烈建议您阅读“认为有害的递归生成”并编写通过Autoconf配置的自己的GNU Makefile。

Pankrat answered 2020-01-16T04:29:47Z

19 votes

此处已经提供了很好的答案，但是如果您有与标准C / C ++项目类似的内容，强烈建议您不要建议编写自己的makefile。 我们需要自动工具而不是手写的makefile，因为automake生成的符合标准的makefile以众所周知的名称提供了许多有用的目标，并且手工提供所有这些目标既繁琐又容易出错。

首先，起初用手编写一个Makefile似乎是一个好主意，但是大多数人不会为编写，安装甚至是干净的规则而烦恼。 automake生成dist，distcheck，clean，distclean，uninstall和所有这些小帮手。 这些其他目标对于最终将安装软件的sysadmin来说是一个很大的福音。

其次，以便携式和灵活的方式提供所有这些目标非常容易出错。 最近，我已经对Windows目标进行了很多交叉编译，并且自动工具的表现非常出色。 与大多数手写文件相比，大多数情况下编译起来很麻烦。 提醒您，可以手动创建一个好的Makefile。 但是请不要高估自己，它需要大量有关一系列不同系统的经验和知识，并且automake可以立即为您创建出色的Makefile。

编辑：并且不要试图使用“替代方案”。 CMake和friends对部署者来说是一个恐怖，因为它们与配置和friends不兼容。 每个中途胜任的sysadmin或开发人员都可以做出色的事情，例如交叉编译，或者做简单的事情，例如在自己的脑海中设置前缀或使用简单的--configure脚本帮助。 但是当您必须与BJam一起做这类事情时，您真该花一三个小时。 别误会我的意思，BJam可能是一个很棒的系统，但使用起来却很麻烦，因为几乎没有项目在使用它，而且文件很少且不完整。 autoconf和automake在已建立的知识方面具有巨大的领先优势。

因此，即使我对这个问题的建议有点迟了：帮个忙，使用自动工具和自动制作。 语法可能有些奇怪，但是它们的性能要比99％的开发人员自己做的更好。

thiton answered 2020-01-16T04:30:28Z

10 votes

对于小型项目，甚至对于仅在一个平台上运行的大型项目，手写的makefile文件都是可行的方法。

当您为需要不同选项的不同平台进行编译时，自动工具真正发挥作用的地方是。 自动工具通常是典型工具的大脑

。/配置

使

进行安装

编译和安装Linux库和应用程序的步骤。

就是说，我觉得自动工具很痛苦，而且我一直在寻找更好的系统。 最近我一直在使用bjam，但这也有其缺点。 祝您好运，找到适合您的产品。

Dan Hook answered 2020-01-16T04:31:15Z

6 votes

需要自动工具，因为不能保证Makefile在不同平台上的工作相同。 如果您手写一个Makefile，并且该文件可以在您的计算机上使用，则很有可能不会出现在我的计算机上。

Zifre answered 2020-01-16T04:31:35Z

6 votes

您知道您的用户将使用什么Unix吗？ 甚至是哪个发行版的Linux？ 您知道他们要在哪里安装软件吗？ 您知道他们拥有什么工具，想要在什么架构上进行编译，拥有多少CPU，可能有多少RAM和磁盘吗？

* nix世界是一个跨平台的环境，您的构建和安装工具需要对此进行处理。

请注意，auto *工具的历史可以追溯到更早的时期，并且有很多关于它们的有效抱怨，但是用更现代的替代方案替代它们的几个项目在发展动力方面遇到了麻烦。

* nix世界中有很多事情。

dmckee answered 2020-01-16T04:32:09Z

2 votes

自动工具是一场灾难。

生成的./configure脚本将检查过去20多年左右在任何Unix系统上都没有的功能。 为此，它花费了大量时间。

运行./configure需要花很长时间。 尽管现代服务器CPU甚至可以具有数十个内核，并且每个服务器可能有多个这样的CPU，但是./configure是单线程的。 我们还有足够长的摩尔定律，CPU核的数量将随着时间的增长而增加。 因此，根据摩尔定律，make花费的时间将保持大致恒定，而并行构建时间每2年减少2倍。 或实际上，我想说make所花费的时间甚至可能由于利用改进的硬件而增加的软件复杂性而增加。

仅向您的项目中添加一个文件的简单操作就要求您运行make、make和m4，这将需要很长时间，然后您可能会发现，由于某些重要文件已更改，因此将重新编译所有文件。 因此，仅添加一个文件，make将重新编译所有内容。

大约是make。生成的构建系统是递归的。 长期以来，递归make被认为是有害的。

然后，当您安装已编译的软件时，您会发现它不起作用。 (想要证明吗？从Github克隆protobuf存储库，签出提交make，将其安装到Debian或Ubuntu系统中，然后请记住：make-因为它位于m4而不是2704679227273774774083；解决方法是在输入make之前执行Makefile)。

理论上讲，通过使用自动工具，您可以创建一个可以在Linux，FreeBSD，NetBSD，OpenBSD，DragonflyBSD和其他操作系统上编译的软件包。 事实呢？ 每个从源代码构建软件包的非Linux系统在其存储库中都有许多补丁文件，可以解决自动工具错误。 只是看看例如 FreeBSD make：充满了补丁。 因此，为每个项目为非自动工具构建系统创建一个小补丁比为每个项目为自动工具构建系统创建一个小补丁要容易。 甚至可能更容易，因为标准make比自动工具更容易使用。

事实是，如果您基于标准make创建自己的构建系统(并按照“递归使之视为有害”的建议，使其具有包容性而非递归性)，则情况将以更好的方式工作。 另外，如果您的项目是一个非常小的项目，包含10-100个C语言文件，并且每个CPU和多个CPU有数十个内核，则构建时间将减少一个数量级，甚至可能减少两个数量级。 将自定义自动代码生成工具与基于标准make的自定义构建系统进行接口连接也比处理m4自动工具混乱要容易得多。 使用标准make，您至少可以在Makefile中键入shell命令。

因此，回答您的问题：为什么要使用自动工具？ 答：没有理由这样做。 自从商用Unix淘汰以来，Autotools就已经淘汰了。 而且多核CPU的出现使自动工具变得过时了。 程序员为何尚未意识到这一点，这是一个谜。 我将在我的构建系统上愉快地使用标准make，谢谢。 是的，生成包含C语言标头的依赖文件需要花费大量的工作，但是由于不必使用自动工具，因此可以节省大量的工作。

juhist answered 2020-01-16T04:33:11Z

0 votes

我不觉得我是专家来回答这个问题，但是还是给您一些我的经验。

因为在某种程度上与为什么我们应该用C语言(高级语言)编写嵌入式代码而不是用汇编语言编写代码相似。两者都解决了相同的目的，但是后者更加冗长，乏味，耗时且更容易出错(除非您非常了解处理器的ISA)。Automake工具和编写自己的makefile的情况相同。编写Makefile.am和configure.ac比编写单个项目Makefile非常简单。

tapeesh answered 2020-01-16T04:33:36Z