8

我在 Autoconf 存档中找到了几个有用的宏，还有一个有用的 m4 文件，它有助于测试 Boost 库的支持。Autoconf 存档由 GNU 托管，而 Boost m4 助手作为 GitHub 存储库托管。我想在使用 Autotools 并由 git 管理的 C++ 项目中使用它们。

显然，可以手动下载它们并插入我项目的 git repo。但是有没有更推荐的方法呢？

例如，可以通过让构建过程自动下载它们来确保第 3 方文件处于最新版本，而不是手动在 repo 中更新它们。它还有助于将源代码与外部文件分开，因为第 3 方文件实际上并不是纯源代码的一部分，而是外部下载的文件。

如果是好东西，是否应该通过autogen.sh手动完成？还是使用 automake.am？或者两者兼而有之（例如在 autogen.sh 中下载文件并在 automake 中测试版本+更新）？

我想将它们保存在 git repo 中并不是一场灾难（就像 COPYING、git.mk 和其他东西一样），但让构建过程将它们更新到网络上的最新版本仍然很有用。

4

2 回答 2

5

相反，autoconf 宏文件是相应源代码的一部分，其重要性足以在make disttarball 中使用。实际上，大多数 autoconf 宏不会经常更改以保证构建中的某种更新功能。即使他们经常更新，也不能保证更新后的宏不会破坏您现有的构建。

将宏置于源代码控制之下是一个好主意。

编辑：我同意@delinquentme 将这些添加为 git 子模块会很好（可以锁定到一个版本，轻松更新）。但我发现这种方法存在一些问题。

第一个是即使使用子模块，git 也不（IIUC）支持部分签出。GNU Autoconf 存档（例如）有很多宏，您可能只需要其中的几个。其余未使用的文件和宏将仍然存在，未使用并妨碍使用。

第二个问题是只在一个AC_CONFIG_MACRO_DIR目录中找到宏，而在该目录中没有子目录搜索，这使得使用多个子模块很烦人。您可以通过在不显眼的地方检查子模块并将它们符号链接到.AC_CONFIG_MACRO_DIR

对我来说，宏观的上游历史并不那么重要。这就是上游的 VCS 的用途:-)。

于 2013-08-05T04:43:05.837 回答
1

您有许多选项可以更细致地处理这些依赖项：

子模块（http://git-scm.com/docs/git-submodule）

... [S] 子模块适用于您希望成为源代码树一部分的不同项目，而这两个项目的历史仍然完全独立，您无法从主项目中修改子模块的内容。[注意： cd-ing 进入 repo 将允许编辑]

钩子（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 子模块到当前目录中的代码库中

于 2014-02-03T23:43:41.630 回答