automake和autoconf是编译代码的标准方法吗?

Modified on: Thu, 12 Jul 2018 06:31:30 +0800

我有时会从源代码编译应用程序,而且我一直在使用:

./configure make sudo make install

但是最近,我遇到了./autogen.sh,它为我生成了configure和make脚本并执行它们。

还有哪些其他方法可以简化C / C ++ / C#(单声道)编译?让它看起来有点老了。那里有新工具吗?鉴于选择,我应该使用哪一个?

最佳答案

Autoconf和Automake开始着手解决Unix的进化问题。

随着Unix向不同方向发展,需要可移植代码的开发人员倾向于编写这样的代码:

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

由于Unix分为不同的实现(BSD,SystemV,许多供应商分叉,以及后来的Linux和其他类Unix系统),对于想要编写可移植代码来编写不依赖于特定品牌的代码的开发人员来说变得非常重要。操作系统,但在操作系统公开的功能。这很重要,因为Unix版本会引入一个新功能,例如“发送”系统调用,以后其他操作系统会采用它。开发人员开始根据功能进行探测,而不是拥有检查品牌和版本的代码意大利面,因此代码变为:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

大多数用于编译源代码的README文件在90年代指向开发人员编辑config.h文件并注释掉系统上可用的正确功能,或者为每个操作系统配置发送标准config.h文件测试

这个过程既麻烦又容易出错,这就是Autoconf的成就。您应该将Autoconf视为一种由具有特殊宏的shell命令组成的语言,该命令能够使用探测操作系统功能的工具替换config.h的人工编辑过程。

您通常会在configure.ac文件中编写探测代码,然后运行autoconf命令,该命令会将此文件编译为您已经看过的可执行配置命令。

所以当你运行./configure && make您正在探测系统上可用的功能,然后使用检测到的配置构建可执行文件。

当开源项目开始使用源代码控制系统时,检查configure.ac文件是有意义的,但不是编译(configure)的结果。 autogen.sh只是一个小脚本,它为您调用带有正确命令参数的autoconf编译器。

-

Automake也因社区现有做法而增长。 GNU项目为Makefile标准化了一组常规目标:

  • make all构建项目
  • make clean将从项目中删除所有已编译的文件
  • make install将安装软件
  • make distmake distcheck之类的东西会准备分发源并验证结果是完整的源代码包
  • 依旧......

构建兼容的makefile变得很麻烦,因为有很多样板被反复重复。所以Automake是一个新的编译器,它与autoconf集成并处理“源”Makefile(名为Makefile.am)到Makefile中,然后可以输入到Autoconf。

automake / autoconf工具链实际上使用了许多其他帮助工具,并且其他组件也会为其他特定任务进行扩充。随着按顺序运行这些命令的复杂性增加,对即用型脚本的需求也随之诞生,这就是autogen.sh的来源。

据我所知,Gnome是介绍使用这个助手脚本autogen.sh的项目


相关问答

添加新评论