Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buck: A high-performance build tool

buckbuild.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Buck: A high-performance build tool

#51

Post by plorkyeran »

nimih wrote: post #40
kadaj wrote: post #37

Software development is all about not re-inventing the wheel. Yet there are countless build systems, tons of pointless frameworks. I wonder developers have nothing else to do. Every company releases their own version of everything.

My understand of Buck (and Pants) is that they are the result of ex-Google employees going to other companies (resp. Facebook, Twitter), realizing that Blaze was more or less the Right Way to do a build system (at least for their set of circumstances), and then being forced to re-implement the ideas from scratch (edit: or memory, or exfiltrated docs/code) because Blaze was not open source. Reusing extant software is…

Bazel is basically current Google employees doing the same thing due to how tightly Blaze is tied to Google infrastructure. Any open source projects or things that may one day be a separate business unit under alphabet rather than part of Google can't use Blaze, so they set out to make a version of Blaze that they can use.

Re: Buck: A high-performance build tool

#54

Post by closeparen »

kadaj wrote: post #37

Software development is all about not re-inventing the wheel. Yet there are countless build systems, tons of pointless frameworks. I wonder developers have nothing else to do. Every company releases their own version of everything.

What's the prior art here? Specifically,

- Support for thousands of related and unrelated codebases in the same repo, with a nuanced understanding of dependencies so that all "dirty" objects, and no others, are rebuilt/retested for each change.

- Hermetic builds to weed out undeclared dependencies.

- Support for remote build cache / remote build workers.

- Understanding of many unrelated languages.

I can't imagine GNU Make being reasonable in this kind of use case. What would you choose?

Re: Buck: A high-performance build tool

#55

Post by diebir »

jitl wrote: post #41

I get the sense that Bazel will end up with a larger ecosystem than Buck, because Google’s Cloud business depends on open-sourcing more stuff, so they’ll put more effort into open-source Bazel. Uber is migrating from Buck to Bazel, for instance.

Buck and monorepo is a disaster (there). A bunch of people from Google forced that stuff down everyone's throat. Concerns and real life problems were simply discarded. Another solution in search of a problem. Not invented here at the extreme.

Re: Buck: A high-performance build tool

#56

Post by antimora »

This is great that we have many options. However, as I am reviewing the various build tools I can't find that suits my needs. Pretty much a lot of the build tools, such as bazel, nix, take over the native language dependency management and build operations. What I would like is a simple build dependency tool, similar to what Amazon has for their build tool called (brazil) that can manage pulling packages locally to build.

Here is what I would like to achieve in own projects:

1. Work on a NodeJS project A that can locally install NPM packages based on packages.json.

2. Have another Python or Go project that build depends on project B.

3. The build tool allows the dependencies pulled either from artifact repository or use checked out version locally.

This build system focuses on the WHAT to build vs HOW to build, which will be driven by project's own build tool, e.g. ant, npm, maven, etc.

I am considering creating my own simple build tool which is inspired by the Amazon's own tooling.

BTW, does not anyone know if I am allowed to develop my own tooling inspired on company's internal tooling? Obviously it won't be exactly the same but taken with lots of inspirational values.

Here is more details on the Amazon's build tool: https://gist.github.com/terabyte/15a2d3d407285b8b5a0a7964dd6...

Re: Buck: A high-performance build tool

#58

Post by Game_Ender »

diebir wrote: post #55
jitl wrote: post #41

I get the sense that Bazel will end up with a larger ecosystem than Buck, because Google’s Cloud business depends on open-sourcing more stuff, so they’ll put more effort into open-source Bazel. Uber is migrating from Buck to Bazel, for instance.

Buck and monorepo is a disaster (there). A bunch of people from Google forced that stuff down everyone's throat. Concerns and real life problems were simply discarded. Another solution in search of a problem. Not invented here at the extreme.

What made Buck fail at Uber vs Facebook? I thought they successfully used it for larger repos there.

Re: Buck: A high-performance build tool

#59

Post by Game_Ender »

entelechy wrote: post #16

We think Buck is great. It's Deterministic hermetic builds and it's composable and declarative high-level build description language made packaging very easy. We built even built a package manager for Buck: https://github.com/LoopPerfect/buckaroo Currently we marketing it for C++ but it can be used for any language that is supported by Buck.

What’s your take on Bazel? Have you considered offering support in Bazel for your package manager?

Re: Buck: A high-performance build tool

#60

Post by lhorie »

mgoblu3 wrote: post #36
lhorie wrote: post #23

Earlier quoted context omitted.

Uber is migrating away from Buck to Bazel. One major reason is poor support for a variety of languages (Go being one big one, where fixing issues was historically slow due to a need to upstream fixes to Buck core). I haven't worked with Buck myself, but colleagues who evaluated it for JS have expressed concerns with lack of support/ecosystem there as well. In comparison, there are various Bazel rulesets for JS/Typesc…

Does this include mobile projects? I know Uber was/is pretty big on the Buck migration

Yes
Post reply on HN