1

我正在研究几台具有不同自动工具版本的超级计算机。

当我做makeafter./configure时，他们中的一些人给了我一个关于错误版本 aclocal 的错误。

如果我在一个平台上重新配置我的 configure.ac，那么在另一个平台上也会发生同样的事情。

例如，一个平台会给我这个：

CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.15
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127

如果我运行autoreconf，它会正常工作。但是，如果我在其他一些平台上使用新生成的 configure.ac，他们会给我不同版本号的相同错误：

CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.13
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127

我知道autoreconf -fi每次去不同的平台时我都可以运行，但我听说让最终用户这样做并不是一个好习惯，因为这需要他们安装自动工具。

他们有三个不同的版本，我不知道如何处理。autoreconf当我运行./configure重新生成配置时，有什么方法可以自动运行？或者有没有更好的方法来解决这个问题？

4

1 回答 1

1

我看到了将源代码分发到不同超级计算机的两种主要方式：

  1. 生成的压缩包make dist

  2. 版本控制的源代码树

如果您使用make dist生成的 tarball（案例 1）将源代码分发到不同的超级计算机，则可以使用从 tarball 中提取的单个源代码树用于所有不同的超级计算机，只要您在不同的 per-超级计算机目录。

如果您使用版本控制的源代码树（案例 2）来开发源代码并将其分发到不同的超级计算机，您有两种选择：

  1. 将make dist生成的文件保存在版本控制中

  2. 将所有生成的文件保留在版本控制之外

如果您将make dist生成的文件保存在版本控制中（案例 21），则每次autoreconf在与生成这些文件的机器不同的机器上运行都会生成一组更改的生成文件，因此对文件进行更改而没有实际的原始更改。所以在这种情况下，你需要定义一个单一的系统，你所有的开发工作都在这个系统上涉及到构建系统。所有其他系统只能在源代码内进行开发。然后，您可以在所有不同的超级计算机上使用单一版本控制的源代码树。

如果您将所有生成的文件保留在版本控制之外（案例 22），您将需要为每台不同的机器创建不同的版本控制源代码树副本，以避免工具版本不匹配。

在像 git 这样的分布式版本控制系统时代，这（案例 22）显然是我的首选。

于 2019-10-30T08:41:44.207 回答