IMO there should be one build system for each language and it should be good at the basics, and if you need more then you should write your own (minimal-dependency) build script in the same language as the code you're building, and in that system you do things like generate build files for the big, complicated thing you're trying to build.
In Java terms, if you have a big complicated Java repo that requires lots of steps to build, you should have a separate Java project in there just for building the main repo. That separate Java project should be built and run with maven, and that separate project can do all kinds of fancy things, but ultimately it will be generating maven projects or calling maven with special command line parameters or something like that.
I even put the logic for CI in my build project like this. It makes everything reproducible and debuggable. How cool is it to be able to put a breakpoint in your build script? How about stepping through your CI code? Things are way simpler this way.
I eschew frameworks in this custom build tool, because the build code should look conventional for whatever language it's written in.
> I eschew frameworks in this custom build tool, because the build code should look conventional for whatever language it's written in.
That's really the case with Mill as well, at a deeper more-meaningful level. Mill builds are all built around objects, classes, methods, and overrides.
Maven is XML. Do you write large codebases in XML? Gradle is Groovy/Kotlin, but it's an odd Groovy/Kotlin dialect or DSL that looks totally unlike application codebases, and your IDE is unable to understand and navigate effectively.
Mill is Scala, sure, but what's important is that it is architected around objects, classes, methods, and overrides. Those are the core abstractions when working with Mill, which are the same core abstractions as any Java/Scala/Kotlin application. Thus IDEs are able to navigate Mill builds, profilers like JProfiler or Yourkit can work on Mill builds, and humans who learned Java 101 in college are immediately familiar with the structure and fundamental abstractions of Mill.
I've seen this taken to extremes (eg Kubernetes deployment as Java code simply because the service is in Java) and it's... terrifying. It's justified in the pre-internet era, where learning two languages would require two trips to the library. These days, I really don't see why not using the better tool for whatever part of the job you're doing. It creates a mountain of complexity for no reason other than "I only want to touch language X"
In Java terms, if you have a big complicated Java repo that requires lots of steps to build, you should have a separate Java project in there just for building the main repo. That separate Java project should be built and run with maven, and that separate project can do all kinds of fancy things, but ultimately it will be generating maven projects or calling maven with special command line parameters or something like that.
I even put the logic for CI in my build project like this. It makes everything reproducible and debuggable. How cool is it to be able to put a breakpoint in your build script? How about stepping through your CI code? Things are way simpler this way.
I eschew frameworks in this custom build tool, because the build code should look conventional for whatever language it's written in.