Well, I think the real issue here is that people have an extremely different and disjunctive perception about what actually constitutes a “build tool”. (That’s actually part of what I wanted to bring into attention in the related build tool thread, but still missed to do so.)
For example regarding Linux one could rightfully declare everything being a dependency of the “build-essential” Debian package to be part of “the build tooling”. (This package would pull in a full Linux system in case you would try to install it separately! Unix / Linux is an extremely tightly coupled monolith, so more or less everything on a minimal system is in the end part of “the build tooling”. In case someone likes to argue: I’m using Linux exclusively for over 20 years and back in the day I used to build my it form scratch. So I think I my opinion here isn’t made out of thin air.)
But if you just declare a tool that can convert a directory and its sub-directories full of Scala source files and some resources into some form of publishable artifact (like a JAR file) a “build tool” should be strictly unnecessary. (Additional packaging options like the creation of an APT package, an AppImage, or maybe even an .exe file could be added on top of this basic packing of course). The whole rigmarole of mapping a directory structure which describes your project and it’s modules already perfectly fine on some “virtual project structure” through obscure configs and tooling makes things just unnecessarily complex, imho. Especially for newcomers! (But not only for them.)
When looking on both above examples I guess we need to start to distinguish different requirements and task-scopes for “build tools”. Form “just give me that JAR file” to the creation of integration tested docker containers there are very different things people want out of a “build tool”. All those requirements / expectations are valid of course.
So imho a divide and conquer approach would be the right here. A bunch of simple tools, each with just narrow focus, would be ideal. Together such tools could still form arbitrary complex build “pipelines”.
I think tools like Bazel do a lot of things right: Just concentrate on one task, but do it really well. Having dependency management, change management, packaging, all kinds of (integration) testing, creating and pulling down whole environments, etc. in one tool is not a good approach, imho. That just leads to infinite feature creep because people have really very different opinions about / requirements for “a build”…
OTOH you need than some high level tool that combines the dedicated and specialized tools to work together to model arbitrary complex “builds” (consisting of everything someone deems to be part of “a build”).
I would love it if scala-cli could be that simple no-config “base tool” that is able to assemble a source directory structure into JARs. But everything else should be kept out of it. “Orchestrating” everything around what one could possibly consider part of a build would be better done by some dedicated tooling, like task runners. (Of course scala-cli could integrate an dependency manager and even some plugins in some form of a distribution. Task runners can be build in Scala. But scala-cli shouldn’t be hard coded to anything like that, imho. Scala’s dependencies are already entangled to a point where you actually can’t build anything of it in a clean way form scratch! That’s why there are no proper Debian packages of the language or its libs since many years – which is an absolutely terrible and miserable state for a software that claims to be OpenSource…)