我在Autoconf Archive中找到了几个有用的宏，还有一个有用的m4文件，它有助于测试Boost库支持。 Autoconf Archive由GNU托管，Boost m4帮助器作为GitHub仓库托管。我想在一个使用Autotools并由git管理的C ++项目中使用它们。
显然，可以手动下载并插入我项目的git仓库。但是有更推荐的方法吗？
例如，通过使构建过程自动下载第三方文件，而不是手动更新它们，可以确保第三方文件是最新版本。它还有助于将源与外部文件分开，因为第三方文件实际上不是纯源代码的一部分，而是外部下载文件。
如果这是一件好事，应该通过autogen.sh手动完成吗？或者使用automake.am？或两者兼而有之（例如在autogen.sh下载文件和在automake中测试版本+更新）？
我想将它们保存在git repo中并不是一场灾难（就像COPYING，git.mk和其他人一样），但是让构建过程从Web上将它们更新为最新版本仍然很有用。 / p>
答案 0 :(得分：5)
相反，autoconf宏文件是corresponding source的一部分，在make dist tarball中非常重要。实际上，大多数autoconf宏都不会经常更改，以保证构建中的某种更新功能。即使他们经常更新，也无法保证更新的宏不会破坏您现有的构建。
将宏保持在源代码管理下是一个好主意。
编辑：我同意@delinquentme将这些添加为git子模块会很好（可以锁定版本，轻松更新）。但我发现这种方法存在一些问题。
第一个是git没有（IIUC）支持部分检查，即使是子模块也是如此。 GNU Autoconf Archive（例如）有 lot 的宏，你可能只需要其中一些。剩下的未使用的文件和宏仍然在那里，未使用，并且妨碍了。
第二个问题是AC_CONFIG_MACRO_DIR只能在一个目录中找到宏，并且该目录中的 no子目录搜索，这使得使用多个子模块很烦人。你可以通过在不显眼的地方检查子模块并将它们符号链接到AC_CONFIG_MACRO_DIR来实现。
对我而言，宏的上游历史并不是那么重要。这就是上游VCS的用途： - ）。
答案 1 :(得分：1)
您可以通过多种方式处理这些依赖关系：
子模块（http://git-scm.com/docs/git-submodule）
... [S] ubmodules适用于您想要制作的不同项目 你的源代码树的一部分，而两个项目的历史仍然存在 保持完全独立，你不能修改的内容 主项目内的子模块。 [注意：cd进入repo将允许编辑]
与您建议的回购方法最相似
对于Git中保存的任何代码特别强大（如Autoconf Archives所有）
冻结到精确提交（https://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/），从而减少破坏构建的可能性
比Hook更少的前端配置
挂钩（http://git-scm.com/book/en/Customizing-Git-Git-Hooks）
与许多其他版本控制系统一样，Git可以在发生某些重要操作时触发自定义脚本。这些钩子有两组：客户端和服务器端。
通过git特定事件运行
Git支持，如果您正在寻找持续集成，而不是冻结资产
我同意@ ldav1s'将它们保留在版本控制之内，但是关于可维护性，知道代码的来源（维护历史记录）可能会有所帮助。随着未来的更新，建立其他人所做的工作似乎是有利的......
TLDR：使用子模块，维护历史记录并完成它。
$ git submodule add http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_am_jobserver.m4
上面的命令会将URL子模块化到当前目录
中的代码库中