不同平台之间 aclocal 版本不匹配的问题
Problem with aclocal version mismatch between different platforms
我在几台超级计算机上工作，它们有不同的 autotools 版本。
当我在 ./configure 之后执行 make 时，其中一些会给我一个关于错误版本的 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 每次我去不同的平台，但我听说让最终用户这样做并不是一个好的做法，因为它需要他们安装自动工具。
他们有三个不同的版本，我不知道如何处理。当我 运行 ./configure 重新生成配置时，有什么方法可以自动 运行 autoreconf 吗？还是有更好的方法来解决这个问题？
我看到将源代码分发到不同超级计算机的两种主要方式：
tarball 由 make dist
版本控制源代码树
如果您使用 make dist 个生成的 tarball（案例 1）将您的源代码分发到不同的超级计算机，您可以使用从 tarball 中提取的单一源代码树用于所有不同的超级计算机，只要您在每个超级计算机的不同目录中构建源代码树。
如果您使用版本控制的源代码树（案例 2）来开发源代码并将其分发到不同的超级计算机，您有两个选择：
将 make dist 生成的文件保留在版本控制中
将所有生成的文件置于版本控制之外
如果您将 make dist 生成的文件保存在版本控制中（案例 21），则与生成这些文件的机器不同的机器上的每个 autoreconf 运行 都会生成一个更改了一组生成的文件，因此在没有实际原始更改的情况下更改了文件。因此，在这种情况下，您需要定义一个系统，您所有的开发工作都在该系统上进行，这涉及到构建系统。所有其他系统只能在源代码内部进行开发。然后你可以在所有不同的超级计算机上使用一个单一版本控制的源代码树。
如果您将所有生成的文件保存在版本控制之外（案例 22），您将需要为每台不同的机器提供不同的版本控制源树副本，以避免工具版本不匹配。
在像 git 这样的分布式版本控制系统时代，这（案例 22）显然是我的首选。
我在几台超级计算机上工作，它们有不同的 autotools 版本。
当我在 ./configure 之后执行 make 时，其中一些会给我一个关于错误版本的 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 每次我去不同的平台，但我听说让最终用户这样做并不是一个好的做法，因为它需要他们安装自动工具。
他们有三个不同的版本，我不知道如何处理。当我 运行 ./configure 重新生成配置时，有什么方法可以自动 运行 autoreconf 吗？还是有更好的方法来解决这个问题？
我看到将源代码分发到不同超级计算机的两种主要方式：
tarball 由
make dist 生成
版本控制源代码树
如果您使用 make dist 个生成的 tarball（案例 1）将您的源代码分发到不同的超级计算机，您可以使用从 tarball 中提取的单一源代码树用于所有不同的超级计算机，只要您在每个超级计算机的不同目录中构建源代码树。
如果您使用版本控制的源代码树（案例 2）来开发源代码并将其分发到不同的超级计算机，您有两个选择：
将
make dist生成的文件保留在版本控制中将所有生成的文件置于版本控制之外
如果您将 make dist 生成的文件保存在版本控制中（案例 21），则与生成这些文件的机器不同的机器上的每个 autoreconf 运行 都会生成一个更改了一组生成的文件，因此在没有实际原始更改的情况下更改了文件。因此，在这种情况下，您需要定义一个系统，您所有的开发工作都在该系统上进行，这涉及到构建系统。所有其他系统只能在源代码内部进行开发。然后你可以在所有不同的超级计算机上使用一个单一版本控制的源代码树。
如果您将所有生成的文件保存在版本控制之外（案例 22），您将需要为每台不同的机器提供不同的版本控制源树副本，以避免工具版本不匹配。
在像 git 这样的分布式版本控制系统时代，这（案例 22）显然是我的首选。