and now we throw BUSY (https://github.com/rochus-keller/BUSY/) onto the pile.
Why do people continue to invent new build systems?
Why should we care that BUSY is statically typed?
It's an inevitable consequence of two basic natural laws. First, every development team will eventually come to dislike some core feature of their current build system. This is true regardless of the build system. Second, developers like to scratch itches.
Build systems are only worth it if they are tiny and already included in the repository (or so common that everyone has them, like make) so that when I build the project, all code necessary to build the project is built (please no download) and executed.
Something like: build.sh executes `cc build.c -o build && ./build` which then builds the software; it's also pretty important that the build system is written in the same language as the rest of the project so that you don't add another dependency just to be able to build. The question is just whether you need that. Is your software really so complex that you can't just build it with a small script or Makefile?
I don't think build systems have peaked yet, so it's good that there are people willing to explore and experiment with new or interesting ideas within that domain.
If the author reads this: kudos to you for being willing to try experimenting with your ideas.
By narrowing breadth, most often by targeting only one ecosystem[1] or making correctness tradeoffs[2], new build systems can be way more expressive and performant. For now.
They’re also fun to write because DAGs are parallelism are cool problems to think about.
[1] e.g. only targeting one language allows you to use that language instead of a generalized DSL to describe your build graph [2] e.g. abandoning sandboxing altogether and using manual invalidation or just trusting the user
I invented a new kind of database https://www.youtube.com/watch?v=OVICKCkWMZE because I was dissatisfied with existing ones that required you to create many indexes on big tables in order to get reasonable query speeds. That doesn't mean my system will gain instant success over Postgres, MySQL, SQLite, SQL Server, etc.
Because none of the existing ones solve everything and they want to try do some aspect better
We might need new infra automation systems though. The commonly recommended "simple" one, ansible, features an intuitive 22-layer precedence hierarchy.
1. Use the same build system for C++, Python, Java, Rust, Golang, etc. Any language should easily plug in.
2. I don't want to have to know exactly which g++/javac/cargo/go commands are being run under the hood.
3. I want to build source code and I also want to "build" release packages, docker containers, compressed asset packs, etc. Anything that starts with files and is "compiled" into an output should be expressible.
4. It should understand how testing works. It should be able to abstract "I need to run FooBarTest since I changed FooBar" from me. I just want to know all my tests passed.
4 1/2. We should be able to run tests in other architectures. Something like KVM could be used to start VMs to run tests on arm platforms from a x86 host.
5. I want to know code coverage for my tests in aggregate across all languages.
6. It should be easy to drop into a debugger for a test or binary.
7. I want to be able to zip up my source code, unzip it in 20 years, rerun the build on new computer, and have the build complete regardless of if I have an internet connection or not.
8. I want a package manager that just dumps source code and build instructions into a folder that the build system understands. This way when I open my source tree crosslinks will "just work" and we don't need to implement a new way to obtain source code + docs for every single language in every single IDE.
8 1/2. The package manager should also be able to fetch compilers/toolchains for things. If I want to cross compile all my code for arm and my code is written correctly it should "just work" without me needing to download something special. I shouldn't need to tell someone on windows to install 5 random unix emulation layers just so they can get a windows version of gcc. The package manager should just create a toolchain directory which contains at least bootstrap compilers.
9. It should expose an API so I can write tools that interface with it efficiently. My tools shouldn't care about the underlying language of my code so I can share tools with other people. EX: How many lines of code are in foobar-service? Does 10. IDEs should take advantage of the build system's metadata and make better autocompletion suggestions. The closest thing here is the Bazel/Buck/Pants/Please family of build systems but surrounding tooling for these does not exist yet (vendoring source code, package management, VMs for tests). Until we have a build system that supplies these features and is simple to use and supported by IDEs we'll keep getting new build systems.