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

On Tuesday, June 18th, 2024 at 5:46 PM, Nevin Liber <nliber(a)gmail.com> wrote: Not sure if this counts but technically the Linux kernel build itself is largely interfaced with via a makefile. The makefile itself may not necessarily be doing *all* the heavy lifting, but you don't start with a "./configure" this or "cmake ." that or "meson setup build" etc, you just run make to get at things like configuration, building, etc. Linux and it's various configurators do point to an alternate, albeit also more-than-a-makefile, way to do things. POSIX make's lack of conditionals for me is the main sticking point, but one solution is separate "parent" makefiles for certain conditions, with common definitions and rules being put in an include file. Then you, say, have one makefile per combination of ASFLAGS/LDFLAGS for a specific build scenario, then you can call your script that interprets conditions and calls the right makefile. You've still got a script involved, but one consisting of a handful of lines you wrote and understand well rather than oodles of generated code. Like systemd though, I think it comes down to the use-case. Most folks aren't thinking about POSIX through and through in their work probably, if they can cross-compile for various targets using one type of host machine, they only have to worry about their application, not their build system, playing by the POSIX rules. I say none of this to defend anything, especially CMake, I'm also not a fan, but it plays to the unfortunate norm out there where the build system just has to work for the author and/or high-profile contributors to a project, focusing on ensuring something will build anywhere probably isn't in most folks' immediate interest. Truth be told, the main thing that does have me focus on it is most of the stuff I work on these days is producing disassemblies of 80s/90s video games, something where the focus of the work *is* the quality of code representation, buildability, ease of modification, etc. so keeping such a thing from being tightly coupled to a specific platform does play heavily into my recent interactions with least common denominators. That and I'm nomadic with operating environments, so I don't want to paint myself into a corner where a project I'm working on is suddenly out in the rain because I bumped back to FreeBSD from Linux or out into some non-UNIX environment entirely. Sticking to POSIX make et. al. rules where possible minimizes that. - Matt G.