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

22

有时我会从源代码编译应用程序，而我一直在使用：

./configure
make
sudo make install

但是最近，我遇到了./autogen.sh为我生成配置和制作脚本并执行它们的脚本。

还有哪些其他简化C / C ++ / C＃（mono）编译的方法？使看起来有点旧。是否有新工具？有了选择，我应该使用哪一个？

compiling programming

— 路易·萨林
source

没有什么像“代码”一样。例如，如果您获得Java代码，则可能会使用maven或ant来构建它，如果您获得Python，则setuptools是一个不错的选择。没有标准的方法来编译任何东西。也许您应该重新提出这个问题。

— diega 2010年

好点子。我实际上是用C＃用Mono编写代码，但是我的问题也适用于C / C ++。

— 路易·萨林

小提示：autogen.sh不会为您执行make，只需配置即可。

— 桑迪

@Sandy autogen.sh主要是自定义脚本，通常会调用，autoreconf但也可能会调用./configure甚至make。我认为它的行为没有任何形式的标准化。主要目的是在具有项目，人们可以运行（而不必知道他们需要召唤内的exetable文件autoreconf）

— umläute

42

开始使用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

上世纪90年代有针对性的开发人员可以使用大多数自述文件来编译源代码，以编辑config.h文件并注释掉系统上可用的适当功能，或者将为经过测试的每种操作系统配置提供标准的config.h文件。

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

通常，您将在文件configure.ac中编写探测代码，然后运行autoconf命令，该命令会将此文件编译为您所看到的可执行configure命令。

因此，在运行时，./configure && make您正在探索系统上可用的功能，然后使用检测到的配置来构建可执行文件。

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

-

Automake也源自社区中的现有实践。GNU项目标准化了Makefile的常规目标集：

make all 将建立该项目
make clean 将从项目中删除所有编译的文件
make install 会安装软件
这样的事情，make dist并make distcheck会为分发做准备，并验证结果是否是完整的源代码包
等等...

构建兼容的makefile变得很繁重，因为有很多重复的样板。因此，Automake是一个新的编译器，与autoconf集成，并将“源” Makefile（名为Makefile.am）处理为Makefile，然后可以将其馈送到Autoconf。

automake / autoconf工具链实际上使用了许多其他辅助工具，并且通过其他组件来扩展它们来完成其他特定任务。随着按顺序运行这些命令的复杂性增加，就需要立即运行的脚本，这就是autogen.sh的来历。

据我所知，Gnome是一个引入了此帮助脚本autogen.sh的项目。

— miguel.de.icaza
source

只是个小问题：GNU标准要求以tarball形式交付生成的文件，以将构建依赖项减少到最少的通用工具。如果您获取原始资源（例如，从版本控制系统获取），则生成的文件将不存在。

— vonbrand 2013年

14

这个区域有两个“大玩家”。Cmake和GNU Autotools。

GNU Autotools是GNU做事的方式，并且相当专注于* nix。这是一种元构建系统，提供了一组工具，这些工具可以生成特定的配置并为您要执行的操作生成文件。这可以帮助您在代码中进行更多更改，而不必直接操纵构建系统，并且可以帮助其他人以非您设计的方式在* nix下构建代码。
Cmake是跨平台的处理方式。Cmake团队以多种方式构建软件，包括GCC，Visual Studio，XCode，Windows，OSX，Solaris，BSD，GNU / Linux等。如果您完全关心代码库的可移植性，那么这就是要走的路。

如前所述，有些人似乎很喜欢Scons。如果您熟悉Python，这可能会在您的工作环境中提供更多的一致性。

Ruby还有一种称为Rake的元构建系统，它本身就很酷，对于已经熟悉Ruby的人来说非常方便。

— 埃利·弗雷（Eli Frey）
source

6

Scons是一种可能的替代品，尽管我没有个人经验。它也用Python实现，这可能是个问题，具体取决于构建环境。

— 茨瓦伦德
source

2

可移植性不是问题，因为Python现在几乎无处不在。到目前为止，关于SCons的主要抱怨是它的速度慢得令人无法接受。有一些调整可以牺牲构建精度来提高速度，但是我不确定它是否仍与Make保持一致。

— Alex B 2010年

3

如果您使用的是C＃/ Mono，则可以使用msbuild（MonoDevelop和Visual Studio使用的.sln / .csproj文件）来管理整个构建过程。

然后，您可以从MonoDevelop进行构建，也可以xbuild在您喜欢的终端中运行命令（在Mono> = 2.6中效果最佳）。这非常简单，几乎不需要任何工作，因为MonoDevelop会为您处理msbuild文件，除非您想要调整超出MonoDevelop UI可以为您做的事情，否则您将不需要编辑它们。

我不熟悉依赖msbuild的人如何处理其项目的安装，但是您总是可以这样问。;-)

— 沙
source

是的，我了解xbuild，但是我正试图摆脱那些只想牵我的手的IDE。另外，Mono使用Mono编译并使用autoconf，因此我想了解更多信息。谢谢！

— 路易·萨林

1

有趣的是，由于xbuild运行良好，许多Mono项目正在尝试迁移到msbuild。它使Windows / Mac支持更加容易。Mono有太多的C代码，所以我不确定他们迁移到xbuild会有多实际。但是autoconf效果很好，因此对您有用的任何事情都可以做。:-)

— 桑迪

0

对于C＃，您可以使用xbuild（和Windows上的msbuild），这将从项目文件中构建项目。