当我们可以编写自己的 makefile 时，为什么要使用像 Autotools 这样的构建工具呢？
最近，我将开发环境从Windows切换到Linux。 到目前为止，我只使用Visual Studio进行C++开发，所以很多概念，比如 make 和 Autotools 对我来说是新的。 我已经阅读了 GNU makefile 文档并且对它有了大致的了解。 但我对 Autotools 有点困惑。
据我所知，makefile 用于使构建过程更容易。
- 为什么我们需要 Autotools 这样的工具来创建 makefile？ 由于所有人都知道如何创建 makefile，因此我没有真正使用 Autotools。
- 标准是什么？ 我们需要使用这样的工具还是只需要手写的 makefile 就可以了？
Recently, I switched my development environment from Windows to Linux. So far, I have only used Visual Studio for C++ development, so many concepts, like make and Autotools, are new to me. I have read the GNU makefile documentation and got almost an idea about it. But I am kind of confused about Autotools.
As far as I know, makefiles are used to make the build process easier.
- Why do we need tools like Autotools just for creating the makefiles? Since all knows how to create a makefile, I am not getting the real use of Autotools.
- What is the standard? Do we need to use tools like this or would just handwritten makefiles do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您在这里讨论的是两个独立但相互交织的事物：
在 Autotools 中，您有几个项目：
让我们分别看看每个项目。
Autoconf
Autoconf 可以轻松扫描现有树以查找其依赖项并创建可在几乎任何类型的 shell 下运行的配置脚本。 配置脚本允许用户控制构建行为（即
--with-foo、--without-foo、--prefix、--sysconfdir等）以及进行检查以确保系统可以编译程序。配置生成一个 config.h 文件（来自模板），程序可以包含该文件来解决可移植性问题。 例如，如果未定义
HAVE_LIBPTHREAD，请改用 forks。我个人在很多项目中使用 Autoconf。 人们通常需要一些时间来习惯m4。 不过，它确实节省了时间。
您可以让 makefile 继承configure 找到的一些值，而无需使用automake。
Automake
通过提供一个简短的模板来描述将构建哪些程序以及构建它们需要链接哪些对象，可以自动创建符合 GNU 编码标准的 Makefile。 这包括依赖性处理和所有必需的 GNU 目标。
有些人发现这更容易。 我更喜欢编写自己的 makefile。
Libtool
Libtool 是一个非常酷的工具，用于简化任何类 Unix 系统上共享库的构建和安装。 有时我会用它； 其他时候（特别是当只是构建静态链接对象时）我手动完成。
还有其他选项，请参阅 StackOverflow 问题Autoconf 和 Autotools 的替代品？。
构建自动化& GNU 编码标准
简而言之，如果您向大众发布代码，您确实应该使用某种可移植的构建配置系统。 你用什么取决于你。 众所周知，GNU 软件几乎可以在任何东西上构建和运行。 然而，您可能不需要遵守这样的（有时甚至是极其迂腐的）标准。
如果有的话，如果您正在为 POSIX 系统编写软件，我建议您尝试一下 Autoconf。 仅仅因为 Autotools 生成了与 GNU 标准兼容的构建环境的一部分，并不意味着您必须遵循这些标准（许多标准不需要！）:) 还有很多其他选项。
编辑
不要害怕 m4 :) 总有 Autoconf 宏存档 。 有很多例子，或者检查一下。 编写您自己的或使用经过测试的内容。 Autoconf 经常与 Automake 混淆。 它们是两个不同的东西。
You are talking about two separate but intertwined things here:
Within Autotools, you have several projects:
Let's look at each one individually.
Autoconf
Autoconf easily scans an existing tree to find its dependencies and create a configure script that will run under almost any kind of shell. The configure script allows the user to control the build behavior (i.e.
--with-foo,--without-foo,--prefix,--sysconfdir, etc..) as well as doing checks to ensure that the system can compile the program.Configure generates a
config.hfile (from a template) which programs can include to work around portability issues. For example, ifHAVE_LIBPTHREADis not defined, use forks instead.I personally use Autoconf on many projects. It usually takes people some time to get used to m4. However, it does save time.
You can have makefiles inherit some of the values that configure finds without using automake.
Automake
By providing a short template that describes what programs will be built and what objects need to be linked to build them, Makefiles that adhere to GNU coding standards can automatically be created. This includes dependency handling and all of the required GNU targets.
Some people find this easier. I prefer to write my own makefiles.
Libtool
Libtool is a very cool tool for simplifying the building and installation of shared libraries on any Unix-like system. Sometimes I use it; other times (especially when just building static link objects) I do it by hand.
There are other options too, see StackOverflow question Alternatives to Autoconf and Autotools?.
Build automation & GNU coding standards
In short, you really should use some kind of portable build configuration system if you release your code to the masses. What you use is up to you. GNU software is known to build and run on almost anything. However, you might not need to adhere to such (and sometimes extremely pedantic) standards.
If anything, I'd recommend giving Autoconf a try if you're writing software for POSIX systems. Just because Autotools produce part of a build environment that's compatible with GNU standards doesn't mean you have to follow those standards (many don't!) :) There are plenty of other options, too.
Edit
Don't fear m4 :) There is always the Autoconf macro archive. Plenty of examples, or drop in checks. Write your own or use what's tested. Autoconf is far too often confused with Automake. They are two separate things.
首先，正如tinkertim 已经指出的那样，Autotools 不是一个不透明的构建系统，而是一个松散耦合的工具链。 让我添加一些关于 Autoconf 和 Automake 的想法：
Autoconf 是一个配置系统，它基于功能检查创建配置脚本，该脚本应该适用于各种平台。 15 年来，大量系统知识已融入其 m4 宏数据库中它的存在。 一方面，我认为后者是 Autotools 尚未被其他东西取代的主要原因。 另一方面，当目标平台更加异构且 Linux、AIX< 时，Autoconf 曾经变得更加重要/a>, HP-UX, SunOS，...，并且必须支持多种不同的处理器架构。 如果您只想支持最新的 Linux 发行版和与 Intel 兼容的处理器，我真的不明白它的意义。
Automake 是 GNU Make 的抽象层，充当来自更简单模板的 Makefile 生成器。 许多项目最终摆脱了 Automake 抽象并恢复为手动编写 Makefile，因为您失去了对 Makefile 的控制，并且您可能不需要所有混淆 Makefile 的预设构建目标。
现在来看看替代方案（我强烈建议根据您的要求选择 Autotools 的替代方案）：
CMake 最显着的成就是取代了 KDE。 如果您想要拥有类似于 Autoconf 的功能而不需要 m4 特性，那么它可能是您可以获得的最接近的结果。 它带来了 Windows 支持，并已被证明适用于大型项目。 我对 CMake 的不满是，它仍然是一个 Makefile 生成器（至少在 Linux 上），并且存在所有内在问题（例如 Makefile 调试、时间戳签名、隐式依赖顺序）。
SCons 是用 Python 编写的 Make 替代品。 它使用 Python 脚本作为构建控制文件，允许非常复杂的技术。 不幸的是，它的配置系统无法与Autoconf相提并论。 当适应特定要求比遵循惯例更重要时，SCons 通常用于内部开发。
如果你真的想坚持使用 Autotools，我强烈建议阅读 Recursive Make Thought有害（已存档）并编写通过 Autoconf 配置的您自己的 GNU Makefile。
First of all, the Autotools are not an opaque build system but a loosely coupled tool-chain, as tinkertim already pointed out. Let me just add some thoughts on Autoconf and Automake:
Autoconf is the configuration system that creates the configure script based on feature checks that are supposed to work on all kinds of platforms. A lot of system knowledge has gone into its m4 macro database during the 15 years of its existence. On the one hand, I think the latter is the main reason Autotools have not been replaced by something else yet. On the other hand, Autoconf used to be far more important when the target platforms were more heterogeneous and Linux, AIX, HP-UX, SunOS, ..., and a large variety of different processor architecture had to be supported. I don't really see its point if you only want to support recent Linux distributions and Intel-compatible processors.
Automake is an abstraction layer for GNU Make and acts as a Makefile generator from simpler templates. A number of projects eventually got rid of the Automake abstraction and reverted to writing Makefiles manually because you lose control over your Makefiles and you might not need all the canned build targets that obfuscate your Makefile.
Now to the alternatives (and I strongly suggest an alternative to Autotools based on your requirements):
CMake's most notable achievement is replacing AutoTools in KDE. It's probably the closest you can get if you want to have Autoconf-like functionality without m4 idiosyncrasies. It brings Windows support to the table and has proven to be applicable in large projects. My beef with CMake is that it is still a Makefile-generator (at least on Linux) with all its immanent problems (e.g. Makefile debugging, timestamp signatures, implicit dependency order).
SCons is a Make replacement written in Python. It uses Python scripts as build control files allowing very sophisticated techniques. Unfortunately, its configuration system is not on par with Autoconf. SCons is often used for in-house development when adaptation to specific requirements is more important than following conventions.
If you really want to stick with Autotools, I strongly suggest to read Recursive Make Considered Harmful (archived) and write your own GNU Makefile configured through Autoconf.
这里已经提供的答案很好，但如果您有类似于标准 C/C++ 项目的内容，我强烈建议您不要采纳编写自己的 makefile 的建议。 我们需要自动工具而不是手写的 makefile，因为由 automake 生成的符合标准的 makefile 以众所周知的名称提供了许多有用的目标，而手动提供所有这些目标是乏味且容易出错的。
首先，手工编写 Makefile 乍一看似乎是个好主意，但大多数人不会费心编写超出所有规则的内容，安装，也许干净。 automake 生成 dist、distcheck、clean、distclean、uninstall 和所有这些小助手。 这些额外的目标对于最终安装您的软件的系统管理员来说是一个巨大的福音。
其次，以可移植且灵活的方式提供所有这些目标很容易出错。 我最近对 Windows 目标进行了大量交叉编译，自动工具的性能非常好。 与大多数手写文件相比，这些文件的编译起来非常痛苦。 请注意，手动创建一个好的 Makefile 是可能的。 但不要高估自己，这需要大量关于大量不同系统的经验和知识，而 automake 会立即为您创建出色的 Makefile。
编辑：并且不要试图使用“替代方案”。 CMake 及其朋友对于部署者来说是一种恐惧，因为它们与配置和朋友的接口不兼容。 每个半途而废的系统管理员或开发人员都可以做伟大的事情，例如交叉编译或简单的事情，例如在他的头脑中设置前缀或使用简单的 --help 配置脚本。 但当你不得不用 BJam 做这样的事情时，你就该花一三个小时了。 不要误会我的意思，BJam 可能是一个很棒的系统，但使用起来很麻烦，因为几乎没有项目使用它，文档也很少且不完整。 autoconf 和 automake 在现有知识方面拥有巨大的领先优势。
所以，尽管我对这个问题的建议有点晚了：帮自己一个忙，使用 autotools 和 automake。 语法可能有点奇怪，但它们比 99% 的开发人员自己做的要好得多。
The answers already provided here are good, but I'd strongly recommend not taking the advice to write your own makefile if you have anything resembling a standard C/C++ project. We need the autotools instead of handwritten makefiles because a standard-compliant makefile generated by automake offers a lot of useful targets under well-known names, and providing all these targets by hand is tedious and error-prone.
Firstly, writing a Makefile by hand seems a great idea at first, but most people will not bother to write more than the rules for all, install and maybe clean. automake generates dist, distcheck, clean, distclean, uninstall and all these little helpers. These additional targets are a great boon to the sysadmin that will eventually install your software.
Secondly, providing all these targets in a portable and flexible way is quite error-prone. I've done a lot of cross-compilation to Windows targets recently, and the autotools performed just great. In contrast to most hand-written files, which were mostly a pain in the ass to compile. Mind you, it is possible to create a good Makefile by hand. But don't overestimate yourself, it takes a lot of experience and knowledge about a bunch of different systems, and automake creates great Makefiles for you right out of the box.
Edit: And don't be tempted to use the "alternatives". CMake and friends are a horror to the deployer because they aren't interface-compatible to configure and friends. Every half-way competent sysadmin or developer can do great things like cross-compilation or simple things like setting a prefix out of his head or with a simple --help with a configure script. But you are damned to spend an hour or three when you have to do such things with BJam. Don't get me wrong, BJam is probably a great system under the hood, but it's a pain in the ass to use because there are almost no projects using it and very little and incomplete documentation. autoconf and automake have a huge lead here in terms of established knowledge.
So, even though I'm a bit late with this advice for this question: Do yourself a favor and use the autotools and automake. The syntax might be a bit strange, but they do a way better job than 99% of the developers do on their own.
对于小型项目甚至仅在一个平台上运行的大型项目，手写 makefile 是最佳选择。
当您为需要不同选项的不同平台进行编译时，自动工具真正发挥作用的地方。 编译和安装步骤背后的大脑
典型./configure
make
make install
Autotools 通常是Linux 库和应用程序的
。 也就是说，我发现自动工具很痛苦，我一直在寻找更好的系统。 最近我一直在使用 bjam，但这也有其缺点。 祝你好运找到适合你的东西。
For small projects or even for large projects that only run on one platform, handwritten makefiles are the way to go.
Where autotools really shine is when you are compiling for different platforms that require different options. Autotools is frequently the brains behind the typical
./configure
make
make install
compilation and install steps for Linux libraries and applications.
That said, I find autotools to be a pain and I've been looking for a better system. Lately I've been using bjam, but that also has its drawbacks. Good luck finding what works for you.
需要自动工具是因为 Makefile 不能保证在不同平台上同样工作。 如果你手写一个 Makefile，并且它在你的机器上可以运行，那么它很可能在我的机器上无法运行。
Autotools are needed because Makefiles are not guaranteed to work the same across different platforms. If you handwrite a Makefile, and it works on your machine, there is a good chance that it won't on mine.
你知道你的用户将使用什么unix吗？ 或者甚至是哪个 Linux 发行版？ 您知道他们想要将软件安装在哪里吗？ 您是否知道他们有什么工具、他们想要在什么架构上进行编译、他们有多少个 CPU、有多少 RAM 和磁盘可供他们使用？
*nix 世界是一个跨平台的环境，您的构建和安装工具需要处理这个问题。
请注意，自动* 工具可以追溯到更早的时代，并且有许多关于它们的有效抱怨，但是用更现代的替代品取代它们的几个项目却很难发展出很大的动力。
*nix 世界里很多事情都是这样。
Do you know what unix your users will be using? Or even which distribution of Linux? Do you know where they want software installed? Do you know what tools they have, what architecture they want to compile on, how many CPUs they have, how much RAM and disk might be available to them?
The *nix world is a cross-platform landscape, and your build and install tools need to deal with that.
Mind you, the auto* tools date from an earlier epoch, and there are many valid complaints about them, but the several projects to replace them with more modern alternatives are having trouble developing a lot of momentum.
Lots of things are like that in the *nix world.
Autotools 是一场灾难。
生成的
./configure脚本会检查过去 20 年左右任何 Unix 系统上都没有的功能。 为此，需要花费大量的时间。运行
./configure需要很长时间。 尽管现代服务器 CPU 甚至可以有数十个内核，并且每个服务器可能有多个这样的 CPU，但./configure是单线程的。 摩尔定律还有足够长的时间，CPU 核心的数量将随着时间的推移而大幅增加。 因此，./configure花费的时间将保持大致恒定，而根据摩尔定律，并行构建时间每 2 年减少 2 倍。 或者实际上，我想说，由于利用改进的硬件增加了软件复杂性，./configure花费的时间甚至可能会增加。仅向项目添加一个文件这一行为就需要运行
automake、autoconf和./configure，这将需要很长时间，然后您可能会发现，由于一些重要文件已更改，因此所有内容都将重新编译。 因此，只需添加一个文件，make -j${CPUCOUNT}就会重新编译所有内容。关于
make -j${CPUCOUNT}。 生成的构建系统是一个递归系统。 递归 make 长期以来被认为是有害的。然后当你安装已经编译好的软件时，你会发现它不能运行。 （想要证据？从 Github 克隆 protobuf 存储库，查看提交
9f80df026933901883da1d556b38292e14836612，将其安装到 Debian 或 Ubuntu 系统，然后嘿，presto:protoc: error while loading共享库: libprotoc.so.15:无法打开共享对象文件:没有这样的文件或目录- 因为它位于/usr/local/lib而不是/usr/lib；解决方法是在输入export LD_RUN_PATH=/usr/local/lib之前代码>制作）。理论上来说，通过使用autotools，你可以创建一个可以在Linux、FreeBSD、NetBSD、OpenBSD、DragonflyBSD和其他操作系统上编译的软件包。 事实呢？ 每个从源代码构建软件包的非 Linux 系统在其存储库中都有大量补丁文件来解决自动工具错误。 只需看一下例如 FreeBSD
/usr/ports：它充满了补丁。 因此，在每个项目的基础上为非 autotools 构建系统创建一个小补丁与在每个项目的基础上为 autotools 构建系统创建一个小补丁一样容易。 或者甚至更容易，因为标准make比自动工具更容易使用。事实是，如果您基于标准
make创建自己的构建系统（并使其具有包容性而不是递归性，遵循“递归 make 被认为有害”论文的建议），那么事情会以一种更高效的方式进行。更好的方式。 此外，如果您的项目是由 10-100 个 C 语言文件组成的非常小的项目，并且每个 CPU 有数十个内核和多个 CPU，那么您的构建时间会缩短一个数量级，甚至可能缩短两个数量级。 将自定义自动代码生成工具与基于标准make的自定义构建系统连接起来也更容易，而不是处理混乱的m4自动工具。 使用标准make，您至少可以在Makefile中键入 shell 命令。那么，回答你的问题：为什么使用自动工具？ 答：没有理由这样做。 自从商业 Unix 过时以来，Autotools 就已经过时了。 多核 CPU 的出现使得自动工具变得更加过时。 为什么程序员还没有意识到这一点，这是一个谜。 我很乐意在我的构建系统上使用标准
make，谢谢。 是的，生成包含 C 语言头文件的依赖文件需要花费一些工作量，但是由于不必与自动工具进行斗争，因此节省了工作量。Autotools is a disaster.
The generated
./configurescript checks for features that have not been present on any Unix system for last 20 years or so. To do this, it spends a huge amount of time.Running
./configuretakes for ages. Although modern server CPUs can have even dozens of cores, and there may be several such CPUs per server, the./configureis single-threaded. We still have enough years of Moore's law left that the number of CPU cores will go way up as a function of time. So, the time./configuretakes will stay approximately constant whereas parallel build times reduce by a factor of 2 every 2 years due to Moore's law. Or actually, I would say the time./configuretakes might even increase due to increasing software complexity taking advantage of improved hardware.The mere act of adding just one file to your project requires you to run
automake,autoconfand./configurewhich will take ages, and then you'll probably find that since some important files have changed, everything will be recompiled. So add just one file, andmake -j${CPUCOUNT}recompiles everything.And about
make -j${CPUCOUNT}. The generated build system is a recursive one. Recursive make has for a long amount of time been considered harmful.Then when you install the software that has been compiled, you'll find that it doesn't work. (Want proof? Clone protobuf repository from Github, check out commit
9f80df026933901883da1d556b38292e14836612, install it to a Debian or Ubuntu system, and hey presto:protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory-- since it's in/usr/local/liband not/usr/lib; workaround is to doexport LD_RUN_PATH=/usr/local/libbefore typingmake).The theory is that by using autotools, you could create a software package that can be compiled on Linux, FreeBSD, NetBSD, OpenBSD, DragonflyBSD and other operating systems. The fact? Every non-Linux system to build packages from source has numerous patch files in their repository to work around autotools bugs. Just take a look at e.g. FreeBSD
/usr/ports: it's full of patches. So, it would have been as easy to create a small patch for a non-autotools build system on a per project basis than to create a small patch for an autotools build system on a per project basis. Or perhaps even easier, as standardmakeis much easier to use than autotools.The fact is, if you create your own build system based on standard
make(and make it inclusive and not recursive, following the recommendations of the "Recursive make considered harmful" paper), things work in a much better manner. Also, your build time goes down by an order of magnitude, perhaps even two orders of magnitude if your project is very small project of 10-100 C language files and you have dozens of cores per CPU and multiple CPUs. It's also much easier to interface custom automatic code generation tools with a custom build system based on standardmakeinstead of dealing with them4mess of autotools. With standardmake, you can at least type a shell command into theMakefile.So, to answer your question: why use autotools? Answer: there is no reason to do so. Autotools has been obsolete since when commercial Unix has become obsolete. And the advent of multi-core CPUs has made autotools even more obsolete. Why programmers haven't realized that yet, is a mystery. I'll happily use standard
makeon my build systems, thank you. Yes, it takes some amount of work to generate the dependency files for C language header inclusion, but the amount of work is saved by not having to fight with autotools.我不觉得我是回答这个问题的专家，但仍然可以用我的经历给你做一些类比。
因为在某种程度上，这类似于为什么我们应该用C语言（高级语言）编写嵌入式代码而不是用汇编语言编写。
两者都解决相同的目的，但后者更冗长、乏味、耗时且更容易出错（除非您非常了解处理器的 ISA）。
Automake 工具和编写您自己的 makefile 的情况也是如此。
编写 Makefile.am 和 configure.ac 比编写单个项目 Makefile 非常简单。
I dont feel I am an expert to answer this but still give you a bit analogy with my experience.
Because upto some extent it is similar to why we should write Embedded Codes in C language(High Level language) rather then writing in Assembly Language.
Both solves the same purpose but latter is more lenghty, tedious ,time consuming and more error prone(unless you know ISA of the processor very well) .
Same is the case with Automake tool and writing your own makefile.
Writing Makefile.am and configure.ac is pretty simple than writing individual project Makefile.