对configure脚本和Makefile.in感到困惑

Question

我目前正在学习如何使用autoconf/ automaketoolchain.我似乎对这里的工作流程有一个大致的了解 - 基本上你有一个configure.ac生成可执行configure文件的脚本.configure然后由最终用户执行生成的脚本以生成Makefiles,因此可以构建/安装程序.

因此,典型最终用户的安装基本上是:

./configure
make
make install
make clean

好的,现在我在这里困惑:

作为开发人员,我注意到自动生成的配置脚本有时不会运行,并且会出错:

config.status: error: cannot find input file: `somedir/Makefile.in' 

这混淆了我,因为我认为配置脚本应该产生的Makefile.in.所以谷歌搜索一些答案,我发现这可以用autogen.sh脚本修复,这基本上"重置"了autoconf环境的状态.一个典型的autogen.sh脚本将是这样的:

aclocal \
&& automake --add-missing \
&& autoconf

好的.但作为终身用户,我终生下载了无数的tarball,我从来没有使用过autogen.sh脚本.我所做的只是解压缩tarball,并执行通常的configure/make/make install/make clean例程.

但作为一个现在正在使用 的开发人员,除非你先运行,否则autoconf它似乎configure并没有真正运行autogen.sh.所以我发现这非常令人困惑,因为我认为最终用户不应该运行autogen.sh.

那么为什么我必须先运行autogen.sh- 才能找到配置脚本Makefile.in？为什么configure脚本不能简单地生成它？

Answer 1

为了真正理解autotools实用程序,你必须记住它们的来源:它们来自一个开源世界,其中有(a)开发人员从源代码​​存储库(CVS,Git等)工作并创建一个包含源代码并将该tar文件放在下载站点上的tar文件或类似文件,以及(b)获取源代码tar文件的最终用户,在其系统上编译该源代码并使用生成的二进制文件.显然,组(a)中的人员也编译代码并使用生成的二进制文件,但组(b)中的人员通常没有或不需要组(a)中的人员需要的所有开发工具.

因此,这些工具的使用是针对这种分裂,其中组(b)中的人员无法访问autoconf,automake等.

当使用autoconf时,人们通常将configure.ac文件(输入到autoconf)签入源代码控制但不检查autoconf的输出,configure脚本(一些项目configure当然会检查脚本:由你自己决定).

当使用automake时,人们通常检查Makefile.am文件(输入到automake),但不检查automake的输出:Makefile.in.

该configure脚本基本上会查看您的系统中包含可能需要或可能不需要的各种可选元素,可以找到它们等等.一旦找到此信息,它就可以使用它来转换各种XXX.in文件(通常,但不仅仅是Makefile.in)到XXX文件(例如,Makefile).

所以步骤通常是这样的:编写configure.ac并Makefile.am检查它们.要从源代码控制检出构建项目,运行autoconf以生成configurefrom configure.ac.运行automake以生成Makefile.infrom Makefile.am.运行configure以生成Makefilefrom Makefile.in.运行make来构建产品.

当您想要发布源代码时(如果您正在开发一个源代码发布的开源产品),您运行autoconf和automake,然后将源代码与configure和Makefile.in文件捆绑在一起,以便构建源代码的人员只需发布需要make和编译器,不需要任何autotools.

因为运行autoconf和automake(以及libtool,如果你使用它)的顺序可能很棘手,有autogen.sh和autoreconf等脚本被检入源代码控制,供源代码控制的开发人员使用,但这些是从源代码发布tar文件等构建的人不需要/使用

Autoconf和automake经常一起使用,但如果你想自己编写,你可以使用没有automake的autoconf Makefile.in.