Historically they have supported a lot of things the others didn't or didn't easily support: cross-compilation, changing the prefix/libdir/datadir, creating tar

Historically they have supported a lot of things the others didn't or didn't easily support: cross-compilation, changing the prefix/libdir/datadir, creating tarballs, "distcheck" to automatically check the tarball works, libtool, etc. Also lots of Linux tools are built around autotools, for example it's much much easier to rpm-ify or deb-ify an autotools tarball. Another example, there's gettext integration for autotools, automated tools for translators might rely on autotools, etc. I'm probably listing the tip of the iceberg as far as network effects. In the Linux/Unix world, autotools is (or at least historically was) what everything and everybody knows how to deal with, and non-autotools is annoyingly nonstandard. Your gyp link there says for example that its main goal is IDE support; a total non-goal for autotools. Unix/Linux C developers largely do not use IDEs. And the autotools goals probably aren't in gyp's list of priorities. So while they both "build the project" they have pretty different goals. The autotools goals don'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. If you're building a package mostly for Linux and maybe OS-X-as-Unix-compatible, especially one in C/C++ and open source, autotools probably still has a lot to recommend it.