[TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register

On Thu, Jun 20, 2024, at 21:43, segaloco via TUHS wrote: [...] [...] The thing about the autotools is that there are two different audiences for different aspects of the system: consumers of the package (sysadmins, porters, distro packagers...) and developers. In general, the developers need to work a little harder to make life of the consumers easier. While some consumers might be fine with (to use the example above) a cpp error diagnostic about a missing include, I imagine most would prefer a "configure time" diagnostic explaining that dependency package foo needs to be installed before they try to build it. Those who are not C or C++ developers wouldn't necessarily know what cpp is, or how to control it.[0] I, for one, appreciate that pretty much any build tool can be integrated into the autotools framework, in part because it acts as a barrier between the consumers and the underlying language-specific build tooling, etc. The same could be (and has been) said of portable Makefiles, but the level of effort would be quite high to achieve what the autotools-generated Makefiles produce out of the box. E.g., the 'make distcheck' target not only drives a full configure and build in a temporary directory, but also verifies that a VPATH build (building separately from the source tree) works. Language-specific build mechanisms are fine as far as it goes. But the more of them you encounter and need to interact with directly, the more friction there is. The audience for such tools is primarily the developer. Python's pip, JavaScript's npm (or yarn, or ...), golang, Rust's cargo, Java's mvn (or ant, or ivy, or ...), Clojure's lein, Perl's ExtUtils::MakeMaker (or Module::Build, or ...), Ruby's gem, ... And tooling to produce documentation is even worse: DocBook, AsciiDoc, reStructuredText. Even driving LaTeX has become complicated (PDFLaTeX, XeTeX, LuaTeX, ...). The developer who necessarily understands such things can, with some effort, integrate them into an autotools build, making life much easier for the consumers of the package (assuming the integration has been done well). When the audience or consumer of the package is sysadmins (including end-users acting as their own sysadmin), porters, and distro packagers, I think "the usual dance" of "./configure && make" is nice because it is consistent across underlying languages, compilers, and whatever auxiliary tools are needed to produce documentation, etc. And I happen to like m4 :-) *ducks* -Al [0] Sadly, the days when C was the lingua franca amongst programmers seem to be behind us. -- a l a n d. s a l e w s k i ads(a)salewski.email salewski(a)att.net https://github.com/salewski