This is probably the most successfull software used in this arena. As with IMake, these tools also have a common database and take some package specific data on their input to produce some kind of build information on their output. However here the similarity ends.
The common database in autoconf does not contain host specific dependencies as in IMake, but templates for the program requirements. The maintainer of the package uses these common templates from this database to describe the actual program requirements. If a requirement exists that has no template in the common database, autoconf can be easily extended and customized on a per-package basis. There is even a possibility to create extension packages for autoconf with additional templates so templates common to a set of packages can be easily shared among them.
The autoconf suite uses M4 to produce its output and since M4 is a general purpose text processor, strange interactions between M4 and the templates in autoconf or packages using it are much rarer. As autoconf evolved, the diversity of M4 preprocessors able to handle it was reduced to one single program (GNU M4) thus decreasing the probability of strange interactions between autoconf and M4 to almost zero.
The output of autoconf is not a set of "makefiles" but a shell script that does the actual work of configuring the package for build. This script is notorically known as configure and is produced by combining the templates with package-specific data. This shell script does all the actual work. It works by executing a sequence of tests. Using results of these tests it sets a bunch of platform specific variables, which are then used in the build process. After the testsuite is over, the "makefiles" and other customized files are created and the build can begin.
This works well when the platform on which the software is being built is the same as the one on which the software is executed, which is the mode used in wast majority of compilations. In this compilation setup special checks can be executed to ensure that the features chosen for use are not broken and really will do the best work for the software.
When doing cross-compilation, the target platform (that is the platform on which the resulting binary will run) cannot be probed for features so the script must guess reasonable values for the platform specific variables on its own. For that purpose it uses a platform specifier, which is a dash-separated tuple containing 3 or 4 items. The content of the tuple states the CPU on the machine, the operating system, the vendor which produced the platform and in some cases the name of the kernel if the operating system supports multiple kernels (an example of such an operating system is GNU; currently it can run on top of two kernels: Linux and HURD).
The benefits of this appoarch taken by autoconf is evident. Since the autoconf templates present in the packages describe the program requirements rather than host dependencies, the resulting scripts can successfully configure packages for build on a platform the autoconf itself had never known about.