3 ms·

Could anyone speak to why you would use Autotools today in a new project rather than gyp [0] (created by the Chrome team because Autotools sucks) or waf [1]? Ho

Could anyone speak to why you would use Autotools today in a new project rather than gyp [0] (created by the Chrome team because Autotools sucks) or waf [1]? How many people really have a requirement to support more than just Windows, OS X, and Linux? I can understand not wanting to rip out a working Autotools implementation of a legacy project, but it's greenfield use should decline to zero. [0] https://gyp.gsrc.io/ https://gyp.gsrc.io/ [1] https://github.com/waf-project/waf https://github.com/waf-project/waf

kazinator 11y ago
autotools isn't mainly a build system; it's a system for preparing a program which will self-configure and build in various systems. Those systems themselves do not have any special tools installed. No Autotools, no GNU-anything. Autotools was intended to solve the problem of how to give the same tarball of code to a user of SunOS 4, Ultrix, HP-UX 8, and so on, such that each of those users could just unpack the tarball, run ./configure and then make. (Using the make that came with their OS, not CMake, not GNU Make, not gyp and so on). Some of the requirements don't hold as much any more; you can rely on newer POSIX shell features in a configure script, and GNU make is more widely available and so on, but the basic idea is solid: no requirement for any exotic build system just to get the program running. It's the implementation that sucks in Autotools. The high level ideas are solid.
hp 11y ago
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.

kazinator 11y ago

autotools isn't mainly a build system; it's a system for preparing a program which will self-configure and build in various systems. Those systems themselves do not have any special tools installed. No Autotools, no GNU-anything. Autotools was intended to solve the problem of how to give the same tarball of code to a user of SunOS 4, Ultrix, HP-UX 8, and so on, such that each of those users could just unpack the tarball, run ./configure and then make. (Using the make that came with their OS, not CMake, not GNU Make, not gyp and so on). Some of the requirements don't hold as much any more; you can rely on newer POSIX shell features in a configure script, and GNU make is more widely available and so on, but the basic idea is solid: no requirement for any exotic build system just to get the program running. It's the implementation that sucks in Autotools. The high level ideas are solid.

hp 11y ago

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.