The golden idea in autotools is <i>test for features not for versions</i>. Allow me to explain.<p>The problem autotools tries to solve is building your software on a wide array of operating systems and configurations. A very attractive alternative approach taken by most, including CMake[1], is to have a big giant database of systems and what each system can do at which version. Thus, if you want to use a library such as, say, Qt, CMake has a Qt module that looks for Qt libraries, checks their versions, and reports that back to you. These databases of system versions and what is available at each version are necessarily always outdated.<p>Autotools instead gives you tools to write tests. Do you need this library? Which functions do you need from this library? What should those functions do?<p>When you&#x27;re running a .&#x2F;configure script, that&#x27;s what autotools is doing. It&#x27;s checking to see what kind of C library you have, what kind of Unix tools are available, how do those Unix tools behave. It is not going to trust version strings or software names. Perhaps the OS reports that it&#x27;s Debian but in fact it&#x27;s some derivative of Debian that changed some things around. If you were relying on CMake&#x27;s hypothetical database of Debian features, it would fail on this not-quite-Debian system.<p>Over time, these tests get shared around and become part of the core autotools libraries, which is the other problem: autotools is now checking for the absence of certain features that have not really been missing in any system since 1995.<p>---<p>[1] CMake can perform autoconf-like feature checks too, but this is not as common as relying on its databases of systems and features.