> Flexibility is not something I want in a build system. [...] "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later.
We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system users than the build system authors. One is more easily fixable.
At least in Maven, the answer here is simple: write your own plugin.
You can do whatever you want, but you're still operating within the confines of the build system so you've not lost the ability to see what's going on.
It's not all that common that I see an "advanced task" that actually belongs in the build, though -- more often I see people who have decided to fight against their tooling rather than working with it.
I've experienced this myself in a number of different environments. But I'm still not satisfied with the results with the more flexible tooling, usually. I think it's because they commonly lack scaffolding that I want a majority of the time.
The older I get, the more I realize that the lisp DSL approach is probably best: provide a simple, declarative walled garden. If I want to change something for my project using the full language, let me, and may the PR reviewers determine my fate. Ruby also seems to adhere to this philosophy, although I don't have a lot of experience with it.
> I'm still not satisfied with ... more flexible tooling ... they commonly lack scaffolding that I want a majority of the time.
I think this dichotomy, flexibility vs maintainability, reflects build complexity.
Not only do I think the same-language-DSL (a la LISP, as you pointed out), is the 'least bad' choice, I think if we raise our gaze a little the answer here is painfully obvious: how do we handle those issues everywhere else?
In other cases if you need to move files, call some sys commands, structure some data, and express some logic? What if you have to call a webservice with some throttling logic, where is your "build language"? Plop something in a DB? Not to mention that complex builds often have specialized command line apps called by their specialized build langauge.... why?
Complex logic we use programming languages for. Why sacrifice power, components, libraries, compiler-time-checking, and all the rest to use a lesser tool? Full language power, it's The Right Thing.
Confused here. I can't really stop progress waiting on build system features. Extensibility is required like a programming language. Otherwise, you must stop using the build system or build wrappers around it or outside of it making your build even more bespoke than if you used a more flexible system.
Maybe combine a generic non-language specific build system (some variant of Make without the C obsession?) as the outer wrapper around a very language-oriented and inflexible/opinionated build system?
Make doesn't have a C obsession (although the docs do), make works anywhere you have a dependency graph that can be expressed as a file timestamp. Here's an example compiling a c# project: http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).
That's one I haven't looked at much, but can you show me a fake script that does the equivalent of my example? That means a fully incremental build, generating version files, etc. Even things like the version file tend to turn out more complicated in most build systems because they come with a half assed reimplimentation of unix tools
From a quick look t looks like it's task based instead of output based as well, so an incremental build doesn't look simple. Correct me me if I'm wrong, but it looks like it's trying to be a better nant, not a better make.
You're assuming that you're around when the team is building out said system. What if you have the misfortune of inheriting a system where there was plenty of rope to go around?
Still better than having to abandon the build system altogether because it can't do what I want (or work around it which is often worse than leveraging flexible environments in the first place).
Perhaps you can control a team, but how many people do you think you can "control"? Could you control every developer in a division? A company? And how do you onboard new people if any past experience with build systems is worthless because they have to learn how you do your particular build?
And if you find yourself consistently not being able to build a piece of software with a relatively simple build process, perhaps you are trying to do too many weird things?
We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system users than the build system authors. One is more easily fixable.