Ask HN: Do we need another build system?

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 ever get called by foobar-service? The build system's API should be general enough for me to implement this.

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.

Because none of the existing ones solve everything and they want to try do some aspect better

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.

If you instead had a way to say "this one specific thing I am building is special and needs `$magic_extra_arguments` added to it" and the rest of your code is "normal" things will be pretty good.