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

[segaloco via TUHS]

On Tuesday, June 18th, 2024 at 5:46 PM, Nevin Liber <nliber at gmail.com> wrote:

> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson <luther.johnson at makerlisp.com> wrote:
> 
> > I agree with Greg here. In fact even if it was well done, it is
> > declaring something that wasn't really a problem, to be a problem, to
> > insert itself as the solution, but I think it's just extra stuff and
> > steps that ultimately obfuscates and creates yet more dependencies.
> 
> 
> That's a really bold claim. You may not like the solution (I don't tend to comment on it because unlike some here, I recognize that build systems are a Hard Problem and I don't know how to make a better solution), but that doesn't mean it isn't solving real problems.
> 
> But I'll bite. There was the claim by Larry McVoy that "Writing Makefiles isn't that hard".
> 
> Please show these beautiful makefiles for a non-toy non-trivial product (say, something like gcc or llvm), which make it easy to change platforms, underlying compilers, works well with modern multicore processors, gets the dependencies right (one should never have to type "make clean" to get a build working correctly), etc. and doesn't require blindly running some 20K line shell script like "configure" to set it up.
> --
> Nevin ":-)" Liber <mailto:nliber at gmail.com> +1-847-691-1404

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.