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