4 ms·

Things I want to be able to do: 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

Things I want to be able to do: 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 <library with CVE> 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.

anonymoushn 4y ago
What's the workflow for "I need to pass one argument to the linker" in the world where your build tool config doesn't even say which compiler it's invoking but your build fails with a bunch of linker errors?
- gravypod 4y ago
  In Bazel parlance you would write a "rule" or setup a "toolchain" which has the linker args passing setup in it. 99% of code does not need a specific linker arg though and optimizing the happy path for letting you do anything, rather than having a simplified flow that most users care about, makes things more confusing. 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.
  - anonymoushn 4y ago
    It's fairly common for me to download some project that already uses some build automation tool I've never used before and find that it only works on the original developers' machines from a linker error message :)
oweiler 4y ago
Gradle fits your description pretty closely.
- gravypod 4y ago
  Gradle misses almost all of these cases. In my experience it is a very unreliable build system that relies on magic and state in the daemon it starts. You can not trust Gradle to build something from source, edit it, and build again correctly. I have seen many time where you build, edit, build, edit, build, edit, push to upstream and it fails in CI because it fails on a clean build. If you need to "clean" the build system it has failed.

anonymoushn 4y ago

What's the workflow for "I need to pass one argument to the linker" in the world where your build tool config doesn't even say which compiler it's invoking but your build fails with a bunch of linker errors?

gravypod 4y ago
In Bazel parlance you would write a "rule" or setup a "toolchain" which has the linker args passing setup in it. 99% of code does not need a specific linker arg though and optimizing the happy path for letting you do anything, rather than having a simplified flow that most users care about, makes things more confusing. 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.
- anonymoushn 4y ago
  It's fairly common for me to download some project that already uses some build automation tool I've never used before and find that it only works on the original developers' machines from a linker error message :)

oweiler 4y ago

Gradle fits your description pretty closely.

gravypod 4y ago
Gradle misses almost all of these cases. In my experience it is a very unreliable build system that relies on magic and state in the daemon it starts. You can not trust Gradle to build something from source, edit it, and build again correctly. I have seen many time where you build, edit, build, edit, build, edit, push to upstream and it fails in CI because it fails on a clean build. If you need to "clean" the build system it has failed.