Historically they have supported a lot of things the others didn&#x27;t or didn&#x27;t easily support: cross-compilation, changing the prefix&#x2F;libdir&#x2F;datadir, creating tarballs, &quot;distcheck&quot; to automatically check the tarball works, libtool, etc. Also lots of Linux tools are built around autotools, for example it&#x27;s much much easier to rpm-ify or deb-ify an autotools tarball. Another example, there&#x27;s gettext integration for autotools, automated tools for translators might rely on autotools, etc.<p>I&#x27;m probably listing the tip of the iceberg as far as network effects. In the Linux&#x2F;Unix world, autotools is (or at least historically was) what everything and everybody knows how to deal with, and non-autotools is annoyingly nonstandard.<p>Your gyp link there says for example that its main goal is IDE support; a total non-goal for autotools. Unix&#x2F;Linux C developers largely do not use IDEs. And the autotools goals probably aren&#x27;t in gyp&#x27;s list of priorities. So while they both &quot;build the project&quot; they have pretty different goals.<p>The autotools goals don&#x27;t always make sense anymore. For example the historical idea that the shipped tarball would only depend on POSIX sh and not on any other binary made a lot more sense when people were hand-compiling stuff on their HP-UX than it does today where most binaries come from distributions.<p>If you&#x27;re building a package mostly for Linux and maybe OS-X-as-Unix-compatible, especially one in C&#x2F;C++ and open source, autotools probably still has a lot to recommend it.