Problem with aclocal version mismatch between different platforms - automake

Question

I'm working on several supercomputers, which have different autotools versions.
When I do make after ./configure, some of them give me an error about wrong version of aclocal.
If I re-configure my configure.ac on one platform, then same thing happens on the other one.
For example, one platform would give me this:
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.15
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127
If I run autoreconf, it would work fine on it. However, if I use that newly generated configure.ac on some other platforms, they will give me the same error with different version number:
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.13
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127
I know I can just run autoreconf -fi every time I go to a different platform, but I heard it isn't a good practice to make end users to do it as it requires them to install autotools.
They have three different versions, and I don't know how to handle this. Is there any ways to automatically run autoreconf when I run ./configure to regenerate configure? Or is there a better approach to solve this problem?

Answer 1

I see two main ways of distributing your source code to the different supercomputers:
tarballs generated by make dist
version controlled source tree
If you are using make dist generated tarballs (case 1) to distribute your source code to the different supercomputers, you can use one single source tree extracted from the tarball for all different supercomputers, as long as you do out of source tree builds in different per-supercomputer directories.
If you are using a version controlled source tree (case 2) for both developing your source code and distributing it to the different supercomputers, you have two options:
keep the make dist generated files inside version control
keep all generated files outside version control
If you keep the make dist generated files inside of version control (case 21), every autoreconf run on a machine different to the one which generated those files will produce a changed set of generated files, and thus changes to the files without actual raw changes. So in this case, you need to define a single system on which you all development work which touches the build system. All other systems can only do development inside the source code. Then you can use one single version controlled source tree on all different supercomputers.
If you keep all generated files outside of version control (case 22), you will need different copies of the version controlled source tree for each different machine to avoid the tool version mismatches.
In the age of distributed version control systems like git, this (case 22) would clearly be my preferred option.