- Autotools
- GNU编码标准
- Autoconf
- Automake
- Libtool
--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问题Alternatives to Autoconf and Autotools?。
构建自动化和GNU编码标准
简而言之，如果您向大众发布代码，则确实应该使用某种可移植的构建配置系统。您可以自行决定使用什么。GNU软件已知可以在几乎任何系统上构建和运行。但是，您可能不需要遵循如此（有时极端龟毛的）标准。
如果您为POSIX系统编写软件，我建议尝试使用Autoconf。仅因为Autotools生成与GNU标准兼容的构建环境的一部分并不意味着您必须遵循这些标准（许多人都没有！）:) 还有很多其他选择。
编辑
不要害怕m4 :) 总有Autoconf macro archive。有很多示例或可用的检查。编写自己的或使用经过测试的内容。Autoconf太经常与Automake混淆。它们是两个不同的东西。
1
现在来谈谈替代方案（我强烈建议根据您的要求选择Autotools的替代方案）：
CMake的最大成就是在KDE中替代了AutoTools。如果你想要具有类似Autoconf的功能而不带有m4怪异性，那么这可能是最接近Autoconf的选择。它为Windows支持提供了解决方案，并已被证明适用于大型项目。我对CMake的不满在于，它仍然是一个Makefile生成器（至少在Linux上），具有所有固有问题（例如Makefile调试、时间戳签名、隐式依赖顺序）。
SCons是一个用Python编写的Make替代工具。它使用Python脚本作为构建控制文件，允许使用非常复杂的技术。不幸的是，它的配置系统与Autoconf不相匹配。当适应特定要求比遵循公约更重要时，SCons通常用于内部开发。
如果你真的想坚持使用Autotools，我强烈建议阅读Recursive Make Considered Harmful（archived），并编写自己的GNU Makefile通过Autoconf进行配置。
3
首先，手动编写Makefile似乎是个好主意，但大多数人都不会费心编写除all、install和可能的clean之外的规则。 automake生成了dist、distcheck、clean、distclean、uninstall和所有这些小助手。这些额外的目标对最终安装软件的系统管理员非常有益。
其次，在可移植且灵活的方式中提供所有这些目标相当容易出错。我最近进行了很多针对Windows目标的交叉编译，autotools表现得非常好。与大多数手写文件相比，它们通常很难编译。请注意，通过手动方式创建良好的Makefile是可能的。但是不要高估自己，这需要很多关于各种不同系统的经验和知识，并且automake可以立即为您创建出色的Makefile。
编辑：并且不要尝试使用"替代品"。 CMake和其他类似的软件对部署者来说是一种恐怖，因为它们与configure及其相关工具不兼容。任何半路出家的系统管理员或开发人员都可以做出像交叉编译这样的重要任务，或仅仅是通过自己的头脑或使用配置脚本的简单--help设置前缀。但是当您必须在BJam上处理此类事物时，您将为其花费一到三个小时。别误会，BJam在内部可能是一个很棒的系统，但是由于几乎没有项目使用它，并且文档很少而且不完整，因此使用起来非常麻烦。在已建立的知识方面，autoconf和automake在这里拥有巨大的优势。
因此，尽管我对这个问题的建议有点晚：还是请你使用autotools和automake。语法可能有点奇怪，但它们比99%的开发人员自己做的要好得多。
对于小项目或仅在一个平台上运行的大型项目，手写Makefile 是最好的选择。
当您需要为需要不同选项的不同平台编译时，Autotools 真正发挥作用。 Autotools 经常是典型的
./configure
make
make install
Linux 库和应用程序的编译和安装步骤背后的智慧。
尽管如此，我认为 Autotools 会让人感到痛苦，而且我一直在寻找更好的系统。 最近，我一直在使用 bjam，但它也有其缺点。 祝你好运，找到适合自己的方法。
需要使用Autotools，因为Makefile不能保证在不同平台上的工作方式相同。如果您手写一个Makefile，在您的机器上可以工作，但很可能在我的机器上无法正常工作。
*nix世界是一个跨平台的领域，你的构建和安装工具需要处理这个问题。
请注意，auto*工具来自早期时代，有很多合理的抱怨，但是几个项目试图用更现代的替代品取代它们，却难以获得发展势头。
在*nix世界中有很多类似的事情。
关于make -j${CPUCOUNT}。生成的构建系统是递归的。递归make长期以来被认为是有害的。
然后，当您安装已编译的软件时，您会发现它无法正常工作。(需要证明吗？从Github克隆protobuf存储库，检查提交9f80df026933901883da1d556b38292e14836612，将其安装到Debian或Ubuntu系统中，然后嘿——预备： protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory ——因为它在/usr/local/lib而不是/usr/lib; 解决方法是在输入make之前执行export LD_RUN_PATH=/usr/local/lib)。
/usr/ports：它充满了补丁。因此，为每个项目基础上的非Autotools构建系统创建一个小补丁可能比为每个项目基础上的Autotools构建系统创建一个小补丁更容易，甚至更容易，因为标准的make比Autotools更容易使用。事实上，如果你基于标准的
make创建自己的构建系统（并使其具有包容性而不是递归性，遵循“递归make被认为是有害的”论文的建议），事情会更好。此外，如果您的项目非常小，只有10-100个C语言文件，并且每个CPU有数十个核心和多个CPU，则构建时间将降低一个数量级，甚至两个数量级。使用基于标准make的自定义构建系统与自定义自动代码生成工具进行接口也比处理autotools的m4混乱要容易得多。使用标准的make，您至少可以在Makefile中键入shell命令。
因此，回答你的问题：为什么使用autotools？答案是：没有理由这样做。自商业Unix已经过时以来，Autotools一直过时了。多核CPU的出现使Autotools变得更加过时。为什么程序员还没有意识到这一点，是一个谜。我很高兴在我的构建系统中使用标准的make。是的，需要一些工作来生成C语言头文件包含的依赖关系文件，但是不必与autotools斗争，从而节省了大量工作。
1
这在某种程度上与为什么我们应该使用C语言（高级语言）编写嵌入式代码而不是汇编语言非常相似。两者都解决了同样的问题，但后者更冗长、繁琐、耗时，并且更容易出错（除非您非常了解处理器的ISA）。同样的情况也存在于Automake工具和编写自己的makefile之间。编写Makefile.am和configure.ac比编写单个项目的Makefile要简单得多。
原文链接