|
|
|
|
|
|
by twic
4205 days ago
|
|
|
It might be accurate to say that we're doing the wrong things but iterating fast. That's why we have this tumult of tools. Software is definitely not mature enough to just standardise on a few of them. I feel confident in saying that because the thought of permanently standardising on any existing build or configuration management tool fills me with horror. In the JVM world, ant is inadequate, Maven is diabolical, Gradle is a huge step forward but has many warts and one or two fundamental mistakes, and sbt is just vile. Gradle is good enough to be getting on with, but i'm looking forward to the next step. Provided, that is, that the next step is taken after learning from previous steps. Sometimes that happens - Ansible and Salt are clearly attemps to improve on the overcomplexity of Puppet and Chef. Sometimes it doesn't - i'm not sure that Gulp or Leiningen do anything to help. |
|
|
Check out Buck. It's fast, the codebase and general complexity is a tiny fraction compared to Maven or Gradle, and it's more sound in at least one fundamental way. (It uses file hashes instead of modtimes to figure out if a task has to be rerun.)
I agree with the rest of your post. Most build systems suck. Here's an off-hand idea:
All build systems I know work share the same core concept, a directed acyclic graph of tasks. Each task has inputs (which might be the output of another task) and if the inputs are changed then the task is rerun. That same idea also covers a lot of systems for data processing.
Why can't we have a simple, minimal tool for doing only that? Then, we could plug in different task definitions for different uses (eg building a Go project, a Java project, or running a data pipeline).
This seems preferable to a bunch of different application-specific build systems that each roll their own DAG, and their own DSL for defining tasks.