当我们只需编写自己的生成文件时,为什么要使用自动工具之类的生成工具?

你说的是两个相互独立但相互交织的问题:

• 自动工具
• GNU编码标准

在自动工具中,您有几个项目:

• 自动调制解调器
• 汽车制造商
• 利伯特

让我们分别看看每一个。

自动调制解调器

autoconf可以轻松地扫描现有的树以查找其依赖项,并创建一个配置脚本,该脚本几乎可以在任何类型的shell下运行。配置脚本允许用户控制构建行为(即 --with-foo , --without-foo , --prefix , --sysconfdir 以及进行检查以确保系统能够编译程序。

配置生成 config.h 文件(来自模板),程序可以包括该文件来解决可移植性问题。例如,如果 HAVE_LIBPTHREAD 未定义,请改用forks。

我个人在许多项目中使用autoconf。人们通常需要一些时间来适应 m4 . 但是,它确实节省了时间。

您可以让makefiles继承一些配置查找的值,而不使用automake。

汽车制造商

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

有些人觉得这更容易。我更喜欢自己写makefiles。

利伯特

libtool是一个非常酷的工具,可以简化在任何类Unix系统上构建和安装共享库的过程。有时我会使用它;有时(尤其是在构建静态链接对象时),我会手工操作。

还有其他选项,请参阅stackoverflow问题 Alternatives to Autoconf and Autotools? .

构建自动化和GNU编码标准

简而言之,你真的应该使用 一些 如果你把你的代码发布给大众,那就是一种可移植的构建配置系统。你用什么取决于你自己。GNU软件几乎可以在任何东西上构建和运行。但是,您可能不需要遵守这样的(有时甚至是非常学究的)标准。

如果您正在为POSIX系统编写软件,我建议您尝试一下autoconf。仅仅因为自动工具产生了与GNU标准兼容的构建环境的一部分,并不意味着您必须遵循这些标准(很多人不需要!):)还有很多其他选择。

编辑

别害怕M4:)总有 Autoconf macro archive . 大量的例子,或者是检查。写你自己的或使用测试过的东西。autoconf经常与 Automake . 它们是两个分开的东西。

首先,正如Tinkertim已经指出的,自动工具不是不透明的构建系统,而是松散耦合的工具链。让我添加一些关于autoconf和automake的想法:

自动调制解调器 是一个配置系统,它根据应该在各种平台上工作的功能检查创建配置脚本。很多系统知识已经进入 m4 宏数据库在其存在的15年中。一方面,我认为后者是自动工具还没有被其他东西取代的主要原因。另一方面,在目标平台更为异构和Linux的情况下,autoconf过去更为重要。 AIX , HP-UX , SunOS 必须支持、…,以及各种不同的处理器体系结构。如果您只想支持最新的Linux发行版和与Intel兼容的处理器,我真的看不到它的意义。

汽车制造商 是GNUmake的抽象层,充当简单模板的makefile生成器。许多项目最终摆脱了automake抽象,转而手动编写makefiles,因为您失去了对makefiles的控制,并且可能不需要所有隐藏的构建目标来模糊makefile。

现在到 选择 (我强烈建议根据您的要求选择自动工具):

CMake 最显著的成就是在 KDE . 如果你想在没有M4特性的情况下拥有类似autoconf的功能,这可能是最接近的。它将Windows支持带到了桌面上,并已被证明适用于大型项目。我对cmake的看法是它仍然是一个makefile生成器(至少在Linux上是这样),它有所有的内在问题(例如makefile调试、时间戳签名、隐式依赖顺序)。

SCons 是用python编写的make替换。它使用Python脚本作为构建控制文件,允许使用非常复杂的技术。不幸的是,它的配置系统与autoconf不一样。当适应特定需求比遵循惯例更重要时,scons通常用于内部开发。

如果你真的想坚持使用自动工具,我强烈建议你阅读 Recursive Make Considered Harmful 并编写通过autoconf配置的自己的gnu makefile。

这里已经提供的答案是好的,但是我强烈建议如果您有类似于C/C++项目的任何东西,就不要采纳建议来编写自己的Mag文件。我们需要的是自动工具而不是手写的makefile,因为automake生成的标准兼容makefile在众所周知的名称下提供了许多有用的目标,并且手工提供所有这些目标是乏味和容易出错的。

首先,手工编写makefile一开始似乎是一个好主意,但是大多数人不会费心去为所有人编写更多的规则,安装和可能的清理。automake生成dist、distcheck、clean、dist clean、uninstall和所有这些小助手。这些额外的目标对于最终安装软件的系统管理员来说是一个巨大的好处。

其次,以可移植和灵活的方式提供所有这些目标是非常容易出错的。最近我对windows目标做了很多交叉编译,自动工具的性能非常好。与大多数手工编写的文件不同,手工编写的文件大多很难编译。小心点,它 是 可以手工创建一个好的makefile。但是不要高估你自己,它需要大量的经验和知识,关于一堆不同的系统,和automake创建伟大的makefile为你开箱即用。

编辑:和 不要试图使用“备选方案” . cmake和friends对部署者来说是一个恐怖的东西,因为它们的界面与configure和friends不兼容。每一个半途而废的系统管理员或开发人员都可以做一些伟大的事情,比如交叉编译,或者简单的事情,比如在头脑中设置一个前缀,或者用一个简单的——帮助配置脚本。但是当你必须和比哈姆做这些事情的时候,你必须花一到三个小时。别误会我,BJAM可能是一个很好的系统,但它是一个麻烦的屁股使用,因为几乎没有项目使用它,很少和不完整的文件。autoconf和automake在现有知识方面有着巨大的领先优势。

所以,尽管我对这个问题的建议有点晚了:帮你自己一个忙 使用自动工具和自动创建。语法可能有点奇怪,但它们比99%的开发人员自己做的更好。

对于仅在一个平台上运行的小型项目,甚至大型项目,手写的makefile是一种方法。

当您为需要不同选项的不同平台进行编译时,autotools真正闪光的地方是。自动工具通常是典型的

/配置

制作

制作安装

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

也就是说,我发现自动工具是一种痛苦,我一直在寻找一个更好的系统。最近我一直在使用BJAM,但这也有它的缺点。祝你好运,找到适合你的。

因为makefiles不能保证在不同的平台上工作,所以需要自动工具。如果你手工写一个makefile,它在你的机器上工作,很有可能它不在我的机器上。

你知道你的用户将使用什么Unix吗?或者甚至是Linux的哪个发行版?你知道他们想在哪里安装软件吗?你知道他们有什么工具,他们想要在什么架构上编译,他们有多少CPU,他们可以使用多少RAM和磁盘吗?

*nix世界是一个跨平台环境,您的构建和安装工具需要处理这个问题。

请注意,汽车工具可以追溯到一个更早的时代,并且有很多关于它们的有效抱怨,但是用更现代的替代品来替代它们的几个项目发展起来很困难。

在尼克斯世界,很多事情都是这样的。

自动工具是一种灾难。

生成的 ./configure 脚本检查过去20年左右任何UNIX系统上没有的功能。要做到这一点,它需要花费大量的时间。

运行 /配置 需要很长时间。尽管现代的服务器CPU甚至可以有几十个核心,而且每个服务器可能有几个这样的CPU,但是 /配置 是单线程的。我们仍然有足够多年的摩尔定律,CPU核心的数量会随着时间的推移而增加。所以,时间 /配置 由于摩尔定律,Take将保持大约不变,而并行构建时间每2年减少2倍。或者实际上,我会说时间 /配置 由于利用改进的硬件增加了软件的复杂性,使用率甚至可能增加。

只需向项目中添加一个文件,就需要运行 automake , autoconf 和 /配置 这需要很长时间,然后您可能会发现,由于一些重要文件发生了更改,所有内容都将重新编译。所以只添加一个文件,然后 make -j${CPUCOUNT} 重新编译所有内容。

关于 制造商-J$cpucount . 生成的生成系统是递归的。 Recursive make has for a long amount of time been considered harmful .

然后,当您安装已编译的软件时,您会发现它不起作用。(需要证据吗?)克隆 protobuf Github中的存储库,签出提交 9f80df026933901883da1d556b38292e14836612 ,将其安装到Debian或Ubuntu系统,然后hey presto: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory --因为它在里面 /usr/local/lib 而不是 /usr/lib ;解决方法是 export LD_RUN_PATH=/usr/local/lib 打字前 make )

理论上,通过使用autotools,您可以创建一个可以在Linux、freebsd、netbsd、openbsd、dragonflybsd和其他操作系统上编译的软件包。事实?每个从源代码构建包的非Linux系统在其存储库中都有许多补丁文件,可以解决自动工具错误。看看Freebsd /usr/ports :到处都是补丁。因此,在每个项目的基础上为非自动工具构建系统创建一个小补丁要比在每个项目的基础上为自动工具构建系统创建一个小补丁容易得多。或者更简单,作为标准 制作 比自动工具更容易使用。

事实是,如果您基于标准创建自己的构建系统 制作 (并使其具有包容性而不是递归性,遵循“递归使被认为有害”的建议),事情以更好的方式工作。此外,如果您的项目是一个非常小的项目,包含10-100个C语言文件,并且每个CPU和多个CPU有几十个内核,那么您的构建时间会下降一个数量级,甚至可能是两个数量级。将自定义自动代码生成工具与基于标准的自定义生成系统进行交互也更容易。 制作 而不是处理 m4 一团糟的自动工具。用标准 制作 ,您至少可以在 Makefile .

所以,回答你的问题:为什么使用自动工具?答:没有理由这样做。自商业Unix过时以来,自动工具就已经过时了。多核CPU的出现使得自动工具更加过时。为什么程序员还没有意识到这一点,这是个谜。我很乐意使用标准 制作 在我的构建系统上,谢谢。是的,生成C语言头包含的依赖文件需要一定的工作量,但是不必与自动工具进行斗争就可以节省工作量。

我觉得我不是一个专家来回答这个问题,但我还是把我的经验和你作了一个比较。

因为在某种程度上它类似于为什么我们应该用C语言(高级语言)编写嵌入式代码,而不是用汇编语言编写。 两者都解决了相同的目的,但后者更为冗长、乏味、耗时且更容易出错(除非您非常了解处理器的ISA)。 自动生成工具和编写自己的生成文件也是如此。 编写makefile.am和configure.ac比编写单个项目makefile要简单得多。