Buck: A high-performance build tool
buckbuild.com
Buck: A high-performance build tool
1–10 of 71 posts
Re: Buck: A high-performance build tool
#2why are there so many build systems?
it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
Re: Buck: A high-performance build tool
#3why are there so many build systems? it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
Because Google didn't open source Blaze soon enough, and Xooglers who moved to other companies wanted something similar and ended up building clones (Buck and Pants come to mind). Eventually, Google did release an open source version of Blaze called Bazel, but by then the eco-system was already rife with many other similar but slightly different build systems.
Re: Buck: A high-performance build tool
#4why are there so many build systems? it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
I think it boils down to taste, just as there are many languages which have basically the same expressive power. Similarly, there are many shells like bash, tcsh, ...
Re: Buck: A high-performance build tool
#5why are there so many build systems? it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
It's a hard thing to do right despite looking deceptively simple.
Re: Buck: A high-performance build tool
#6why are there so many build systems? it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
Re: Buck: A high-performance build tool
#7why are there so many build systems? it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
Because it’s easy to implement something that does 80% of the features, and also it’s easier than learning all the gnarly features of make
Last year I learned about .PRECIOUS and it was awful
Re: Buck: A high-performance build tool
#8Can anyone who's used both compare Buck to Blaze/Bazel?
Re: Buck: A high-performance build tool
#9why are there so many build systems? it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
- configuration format/language
- system requirements
- convention vs configuration
- flexibility vs predefined paths
- tradeoff features vs their complexity (parallelism, caching, ...)
- level of integration with specific other tooling (VCS, languages, package managers, ...)
Re: Buck: A high-performance build tool
#10why are there so many build systems? it's understandable why programmers have opinions about aesthetics regarding their IDE, language, or framework of choice, but what is there to be opinionated about with a build system?
>, but what is there to be opinionated about with a build system?
I think you're saying this because your idea of a "build system" is a very simple set of sequential steps from known source code input files to an output binary.
The differing opinions come in when the "build system" includes various contradictory philosophies of how to configure and specify the building of complex software.
Different opinions on:
- syntax : should build config be XML, or JSON, or YAML, or custom syntax? E.g. Ant and Maven used XML but Gradle does not
- dependencies search: should build system implicitly find and add relevant dependencies? Or should programmer explicitly specify each one?
- reproducible builds (version pinning) vs auto-updated dependencies.
- should the build system be "smart" about cross-platform differences? If yes, you end up with complicated build tools like GNU Autoconf "configure" bash script, or CMake's complex syntax.
- should build system do optimization and bundling tasks that's not strictly limited to "compile" steps? Some Javascript build tools try to eliminate redundant or unused js code to make downloads smaller.
- etc, etc.
I also recommend reading the blog post "So you want to write a package manager"[1] to get an idea of how complicated a build system can get. The title says "package manager" but much of the material is also about build systems.
The bottom line is that reasonable people can disagree on the priorities and therefore, you can't create The One & Only Build System to End All Other Build Systems.
[1] https://medium.com/@sdboyer/so-you-want-to-write-a-package-m...