我正在使用几台具有不同自动工具版本的超级计算机。
当我在make之后执行./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？还是有更好的方法来解决这个问题？
[我看到了将源代码分发到不同的超级计算机的两种方法：
make dist生成的压缩文件
版本控制的源代码树
[如果您正在使用make dist生成的tarball将源代码分发到不同的超级计算机，则可以对所有不同的超级计算机使用从tarball中提取的一个源代码树，只要您在源代码树中所做的构建不同-超级计算机目录。
如果使用版本控制的源树来开发源代码并将其分发到不同的超级计算机，则有两个选择：
将make dist生成的文件保留在版本控制中
将所有生成的文件保留在版本控制之外
如果将make dist生成的文件保留在版本控制中，则在与生成这些文件的计算机不同的计算机上运行的每个autoreconf都会生成一组已更改的生成文件，因此，这些文件的更改没有实际的原始内容变化。因此，在这种情况下，您需要定义一个系统，所有开发工作都在该系统上进行，该系统与构建系统有关。所有其他系统只能在源代码中进行开发。然后，您可以在所有不同的超级计算机上使用一个受版本控制的源树。
如果将所有生成的文件保留在版本控制之外，则对于每台不同的计算机，将需要版本控制的源树的不同副本，以避免工具版本不匹配。在像git这样的分布式版本控制系统时代，这显然是我的首选。