我是 autotools 新手,正在开发一个 C 项目。我想将我的项目添加到 git 存储库。我需要在版本控制系统中跟踪哪些由自动工具生成的文件,哪些应该被忽略?
您不应将任何未经手工编辑的文件置于版本控制之下。这意味着版本控制系统应该忽略任何生成的文件。我基本上只将以下内容置于版本控制之下:
configure.ac
Makefile.am
AUTHORS
NEWS
等Makefile.am
bootstrap
或
autogen.sh
,当您检查新版本时运行一次。复制出来。您可以在我的一个项目中看到一个示例here。对于更简单的项目,您的
autogen.sh
实际上只需要包含一行:autoreconf --install || exit 1
尽管有些人更喜欢在
./configure
结束时自动运行
autogen.sh
。为什么不在版本控制中跟踪所有生成的文件?因为它们的内容取决于您构建的机器、生成它们的自动工具的版本以及月相。任何时候任何这些更改,生成的自动工具文件都会更改,并且您将在提交中收到大量垃圾。
此外,任何为了构建代码而从版本控制中检查代码的人都应该安装适当的开发工具,因此您真的不需要担心人们因为缺少自动工具而遇到麻烦。
VonC 所说的带有
configure
文件来生成
Makefile
的 C 项目对于 源代码发行版(当您键入
.tar.gz
时获得的 make dist
文件)来说是正确的,但不一定适用于新鲜的从版本控制中签出副本。的答案,并将此答案保留为社区维基。
这对于源代码分发是有意义的,但您的项目可能不是这样。
出于开发目的,ptomato的答案更有意义。
因此,当您考虑自动工具链时,我建议对配置文件之前生成的所有文件进行版本控制,因为它们通常是一次性生成操作。
这意味着任何拥有您的版本项目副本的人都可以立即开始:
./configure
make
make install
因此,虽然这通常是正确的,但您不应该对任何生成的文件进行版本控制,您可以存储这些文件,特别是如果该项目的其他读者可以:
受益于不重新生成这些文件(以获得相同的结果)
ed
是什么?! 🤔
流程图中的
ed
可能是用于修改或创建
configure.ac
和 Makefile.am
文件的文本编辑器的占位符。在 Autotools 的上下文中,这些文件由开发人员编写,用于指定软件的配置和构建指令。
ed
实际上是Unix和类Unix系统中的标准文本编辑器之一,代表了手动编辑这些文件的概念。在 Autotools 工作流程的图形表示中,显示像
ed
这样的编辑器强调了
configure.ac
和 Makefile.am
文件通常是手工制作的,而不是由 Autotools 本身生成的。autoscan
configure.ac
,然后由开发人员使用文本编辑器(在本例中为 ed
)进行编辑,以微调配置过程。