Strengths, weaknesses, opportunities, and threats facing the GNU Autotools
The author says:<p>&gt; I personally don’t think that the Autotools are ... even all that much more difficult to work with than some of the alternatives<p>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.<p>I mean, I&#x27;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.<p>Now, let&#x27;s discuss the listed strengths of autotools:<p>1.  feature-based approach scales better than lists of system quirks. &lt;- this is not specific to autotools.<p>2. 30+ years’ worth of embedded knowledge about portability traps for C programs and shell-based build scripting on Unix  &lt;- this is true, but by now this is significant mostly for legacy systems. Alternatives have, say, 10 years&#x27; worth of such gained embedded knowledge<p>3. Supports cross-compilation better than competing systems. &lt;- I wouldn&#x27;t say that. Needs to be argued explicitly.<p>4. Support software written in multiple languages better than some competing build systems &lt;- 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.<p>5. Autoconf is very extensible, and there are lots of third-party &quot;macros&quot; available. &lt;- This is true for most build systems. Remember, though, that the macros need to be written in an arcane language.<p>6. Produced tarball releases have fewer build dependencies than those produced by competitors. &lt;- Was not aware of this. Let&#x27;s take his word for it.<p>7. Produced Tarball releases have a predictable, standardized (literally; it’s a key aspect of the &quot;GNU Coding Standards&quot;) interface for setting build-time options, building them, testing them, and installing them. &lt;- I&#x27;ll grant him this point too.<p>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. &lt;- This is a rephrasing of a weakness: Only supports Make-based building. &quot;Lots of makes&quot; is a poor substitute for non-Unix-Make building.<p>9. Excellent reference-level documentation &lt;- I&#x27;ll again grant him this, but TBH I haven&#x27;t used autotools documentation so I don&#x27;t know. I do know that CMake documentation is sometimes lacking or not clear enough.<p>10. As they are GNU projects, users can have confidence that Autotools are and will always remain Free Software. &lt;- This is actually an interesting point. Having software that can&#x27;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&#x27;t have an answer to that. I wish the alternatives were GPL&#x27;ed as well.<p>11. Relatedly, users can trust that architectural decisions are not driven by the needs of particular large corporations. &lt;- And this is not true for CMake or Meson?<p>12a. Large installed base &lt;- That&#x27;s almost meaningless. It&#x27;s not hardware.<p>12b. Switching to a competing build system is a lot of work. &lt;- No it isn&#x27;t. For a new project, it is almost 0 work. For an existing project, switching to CMake is _some_ work, but there&#x27;s somepayoff in my limited experience.<p>A few more points:<p>&gt; Autoconf’s core function is to solve a problem that software developers, working primarily in C, had in the 1990s&#x2F;early 2000s (during the Unix wars).<p>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&#x27;m wrong).<p>&gt; 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.<p>This is not actually the case. When we&#x27;re starting a new software project, most of us are developing it for platforms which are 10-years-old or less (I don&#x27;t mean the hardware which might be older - I mean the OS and libraries).<p>&gt; Similarly, maintainers of older programs<p>This is where autotools remains very relevant, in my opinion. Unless its alternatives decide to invest in being more &quot;universal&quot; and supporting older systems&#x2F;platforms.