4 ms·

The author says: > I personally don’t think that the Autotools are ... even all that much more difficult to work with than some of the alternatives So, even o

The author says: > I personally don’t think that the Autotools are ... even all that much more difficult to work with than some of the alternatives So, even one of the main contributors to autotools says he acknowledges that autotools is more difficult to work with than most alternatives, and much more difficult to work with than some of the alternatives. And - it is. I mean, I'm not sure how far back the history goes, but why choose an arcane language like M4 to base autotools on? You had perl in 1980s, or even bash since 1989. Now, let's discuss the listed strengths of autotools: 1. feature-based approach scales better than lists of system quirks. <- this is not specific to autotools. 2. 30+ years’ worth of embedded knowledge about portability traps for C programs and shell-based build scripting on Unix <- this is true, but by now this is significant mostly for legacy systems. Alternatives have, say, 10 years' worth of such gained embedded knowledge 3. Supports cross-compilation better than competing systems. <- I wouldn't say that. Needs to be argued explicitly. 4. Support software written in multiple languages better than some competing build systems <- Undermined by the focus on C and bash a couple of points ago, and by the fact that the author was only willing to make that point relatively, not absolutely, and cherry-pick the reference competitors. 5. Autoconf is very extensible, and there are lots of third-party "macros" available. <- This is true for most build systems. Remember, though, that the macros need to be written in an arcane language. 6. Produced tarball releases have fewer build dependencies than those produced by competitors. <- Was not aware of this. Let's take his word for it. 7. Produced Tarball releases have a predictable, standardized (literally; it’s a key aspect of the "GNU Coding Standards") interface for setting build-time options, building them, testing them, and installing them. <- I'll grant him this point too. 8. Tries very hard to generate Makefiles that will work with any Make implementation, not just GNU make, and not even just (GNU or BSD) make. <- This is a rephrasing of a weakness: Only supports Make-based building. "Lots of makes" is a poor substitute for non-Unix-Make building. 9. Excellent reference-level documentation <- I'll again grant him this, but TBH I haven't used autotools documentation so I don't know. I do know that CMake documentation is sometimes lacking or not clear enough. 10. As they are GNU projects, users can have confidence that Autotools are and will always remain Free Software. <- This is actually an interesting point. Having software that can't devolove into a proprietary variant like with permissive licenses is a good thing in general. But - *is this really a danger for build system generators?* I don't have an answer to that. I wish the alternatives were GPL'ed as well. 11. Relatedly, users can trust that architectural decisions are not driven by the needs of particular large corporations. <- And this is not true for CMake or Meson? 12a. Large installed base <- That's almost meaningless. It's not hardware. 12b. Switching to a competing build system is a lot of work. <- No it isn't. For a new project, it is almost 0 work. For an existing project, switching to CMake is _some_ work, but there's somepayoff in my limited experience. A few more points: > Autoconf’s core function is to solve a problem that software developers, working primarily in C, had in the 1990s/early 2000s (during the Unix wars). The Unix wars were in the 1980s and 1990s mostly. They were dying down in the 2000s, as Linux ascended. I suppose that Solaris, HP-UX, AIX and OpenServer have their niches, but those are small (correct me if I'm wrong). > Developers of new code, today, looking at existing configure scripts and documentation, cannot easily determine which of the portability traps Autoconf knows about are still relevant to them. This is not actually the case. When we're starting a new software project, most of us are developing it for platforms which are 10-years-old or less (I don't mean the hardware which might be older - I mean the OS and libraries). > Similarly, maintainers of older programs This is where autotools remains very relevant, in my opinion. Unless its alternatives decide to invest in being more "universal" and supporting older systems/platforms.

jcranmer 6y ago
> 6. Produced tarball releases have fewer build dependencies than those produced by competitors. <- Was not aware of this. Let's take his word for it. I believe the intent is to say "you need autotools to build the tarball, but the tarball doesn't need autotools, just regular POSIX tools", which is a jab at systems like cmake where you need cmake to do the configuration at tarball time. Except, well, the introduction of DVCSes like git has shifted a lot of software away from "build from tarball" to "build from VCS checkout," so the value is rather lesser. Indeed, you can turn it around and claim that this is an antifeature: it takes more work to build a tarball and do VCS checkout than not.
- derefr 6y ago
  Developers build stuff from VCS checkouts. But the package managers and ports systems that regular users rely upon, still use tarball releases, not VCS checkouts, as their upstreams. For example: Homebrew. If you tell Homebrew to --build-from-source, it'll pull down a release tarball from its release URL; unpack it; set up the shell environment just so; and then run the same very same ./configure script the upstream generated with Autotools. It'd actually be kind of a problematic bootstrapping problem if that ./configure script did require Autotools to run, as there's no real legal way for (proprietary) macOS to ship (GNU, GPLv3) Autotools. And that's much the same problem many other proprietary UNIXes were in, back when: wanting to support "standard" tooling, but being too wary of this new "copyleft" thing to be willing to ship any GPLed software as part of their OS. Thus, the broadest industry support came out for the tooling that doesn't force the upstream's tooling's licensing choices on the downstream. (Ironically, that tooling happened to be from GNU, the precise people whose software they were trying to avoid shipping.)
- einpoklum 6y ago
  > "build from VCS checkout," so the value is rather lesser. But why does building from VCS checkout make any difference? If anything, there are _more_ requirements that way, since a tarball release can possibly be made to rely on less (e.g. generating ad-hoc install scripts).
kevin_thibedeau 6y ago

jcranmer 6y ago

> 6. Produced tarball releases have fewer build dependencies than those produced by competitors. <- Was not aware of this. Let's take his word for it. I believe the intent is to say "you need autotools to build the tarball, but the tarball doesn't need autotools, just regular POSIX tools", which is a jab at systems like cmake where you need cmake to do the configuration at tarball time. Except, well, the introduction of DVCSes like git has shifted a lot of software away from "build from tarball" to "build from VCS checkout," so the value is rather lesser. Indeed, you can turn it around and claim that this is an antifeature: it takes more work to build a tarball and do VCS checkout than not.

derefr 6y ago
Developers build stuff from VCS checkouts. But the package managers and ports systems that regular users rely upon, still use tarball releases, not VCS checkouts, as their upstreams. For example: Homebrew. If you tell Homebrew to --build-from-source, it'll pull down a release tarball from its release URL; unpack it; set up the shell environment just so; and then run the same very same ./configure script the upstream generated with Autotools. It'd actually be kind of a problematic bootstrapping problem if that ./configure script did require Autotools to run, as there's no real legal way for (proprietary) macOS to ship (GNU, GPLv3) Autotools. And that's much the same problem many other proprietary UNIXes were in, back when: wanting to support "standard" tooling, but being too wary of this new "copyleft" thing to be willing to ship any GPLed software as part of their OS. Thus, the broadest industry support came out for the tooling that doesn't force the upstream's tooling's licensing choices on the downstream. (Ironically, that tooling happened to be from GNU, the precise people whose software they were trying to avoid shipping.)
einpoklum 6y ago
> "build from VCS checkout," so the value is rather lesser. But why does building from VCS checkout make any difference? If anything, there are _more_ requirements that way, since a tarball release can possibly be made to rely on less (e.g. generating ad-hoc install scripts).

kevin_thibedeau 6y ago