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

61–70 of 71 posts

Re: Buck: A high-performance build tool

#61

Post by entelechy »

Game_Ender wrote: post #59
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?

> What's your take on Bazel?

Here a couple key points:

- Buck and Bazel are very similar.

- Buck currently models C++ projects better [1].

- Buck leverages remote caches currently better than Bazel [3] - Bazel is very easy to install

- Bazels "toolchains" make it very easy to onboard newcomers (to any project and language) but also ensure the build will run as expected.

- Bazel is less opinionated and more extensible than Buck.

In fact Bazel is so powerful that you can have Buildfiles that download a package manager and use it to resolve more dependencies. This is great to get things off the ground, but makes things less composable because the package manager won't see the whole dependency graph. As a result you might get version conflicts somewhere down the line.

To summarize: I think having a very opinionated build-system is easier to reason and scales usually better.

Communities with very opinionated packaging and build-systems are proving this by having orders of magnitude more packages that eg. the highly fragmented C++ community where configuration is prefered over convention.

> Have you considered offering support in Bazel for your package manager?

Yes we did. As soon as this feature [1] is implemented we will have a 1:1 mapping for C++ Buck Projects and Bazel. Then after a small (automated) refactoring of our Buckaroo packages, you should be able to build any package from the Buckaroo ecosystem with either Buck or Bazel.

Btw. The cppslack community is attempting to create a feature matrix of various build-systems here [2]

[1] https://github.com/bazelbuild/bazel/issues/7568

[2] https://docs.google.com/document/d/1y5ZD8ETyGtxCmtT9dIMDTnWw...

[3] https://github.com/bazelbuild/bazel/issues/7664

Re: Buck: A high-performance build tool

#62

Post by lhorie »

Game_Ender wrote: post #58
diebir wrote: post #55

Earlier quoted context omitted.

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.

My understanding is that Facebook doesn't do Go, so it's always been a second class citizen for Buck. Go folks at Uber were spending a significant amount of time (in the scale of several months) trying to upstream fixes to Buck core, but found that Bazel extensibility allowed them to get similar functionality in a matter of weeks or even days. Buck also didn't seem to have a good story around Thrift/Proto and JS/node.

At Uber, the Java stack is still sort of ok w/ Buck (because Buck handles some things better there), so they're taking a wait-and-see approach until the Bazel ecosystem catches up w/ Buck on the concerns they care about. But long term, we are envisioning implementing a company-wide monorepo, and that sort of entails having a unified build system.

Re: Buck: A high-performance build tool

#63

Post by Bombthecat »

antpls wrote: post #35
malkia wrote: post #30

Also (bazel already mentioned, so no need to), but: Pants - https://www.pantsbuild.org/index.html Please.Build - https://please.build/ Closely related, but functioning bit different: Gn - https://gn.googlesource.com/gn/ (targets ninja). Used by Chromium, Fuchsia, and others Soong - https://android.googlesource.com/platform/build/+/master/REA... (targeting Kati?)

Would it be interesting to list Infrastructure-as-Code tools and cloud pipeline tools in parallel ? At some point, build tools and infrastructure tools may converge : Kubeflow Pipeline (for ML) - https://www.kubeflow.org/docs/pipelines/pipelines-overview/ Tekton Pipeline - https://github.com/tektoncd/pipeline TF Extended - https://www.tensorflow.org/tfx

I'm also pretty sure that this will happen.

Re: Buck: A high-performance build tool

#64

Post by Aeolun »

madhadron wrote: post #24
blattimwind wrote: post #14

> Buck looks at the contents of your inputs, not their timestamps to figure out what needs to be built. As a result, incremental builds should always be correct, so there's no need to perform a clean build. At least one of these new-fangled tools gets at least one part right. The salient point is now of course whether Buck considers the correct set of dependencies as well as negative dependencies.

Buck makes you declare every dependency explicitly. A particular target must specify exactly what files it uses, and when it makes a build, it copies those files from the target and all its dependencies into an empty sandbox and builds there. It's wonderful.

Wonderful until you have a few thousand files you need to declare explicitly.

Or do I misunderstand something here?

Re: Buck: A high-performance build tool

#65

Post by Aeolun »

jasode wrote: post #10
_bz2r wrote: post #2

why 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: - sy…

I feel like there is a ‘best’ answer to most if not all of these questions, and the build system should standardize on whatever that best practice is.

It’s great that Timmy thinks an obscure extension of YAML is the best way to define build configs, but all the rest of the engineers use JSON, so that is what we use.

Re: Buck: A high-performance build tool

#66

Post by dikei »

malkia wrote: post #30

Also (bazel already mentioned, so no need to), but: Pants - https://www.pantsbuild.org/index.html Please.Build - https://please.build/ Closely related, but functioning bit different: Gn - https://gn.googlesource.com/gn/ (targets ninja). Used by Chromium, Fuchsia, and others Soong - https://android.googlesource.com/platform/build/+/master/REA... (targeting Kati?)

Google keep inventing new build systems for their OS projects even when Bazel is available.

Re: Buck: A high-performance build tool

#67

Post by shereadsthenews »

techntoke wrote: post #57

Is it possible to do distributed builds with GCC and LLVM? I would like to see more options for distributing builds across a cluster of servers in order to significantly speed up the build process.

https://docs.bazel.build/versions/master/remote-execution.ht...

Re: Buck: A high-performance build tool

#68

Post by puzzle »

shereadsthenews wrote: post #42
nimih wrote: post #40

Earlier quoted context omitted.

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…

“Reimplementation from scratch” seems like a generous description of Buck. It was initially so like Blaze that I always assumed a xoogler exfiltrated at least the documentation of Blaze.

I remember that being a former Google intern.

Re: Buck: A high-performance build tool

#69

Post by jingwen »

techntoke wrote: post #57

Is it possible to do distributed builds with GCC and LLVM? I would like to see more options for distributing builds across a cluster of servers in order to significantly speed up the build process.

(Disclaimer: Bazel engineer)

Bazel does ecosystem and language agnostic distributed builds with both GCP and self-hosted solutions.

Here's a demonstration of building the Angular project remotely: https://youtu.be/lDyIc2Abkwg?t=593

Re: Buck: A high-performance build tool

#70

Post by jingwen »

Aeolun wrote: post #64
madhadron wrote: post #24

Earlier quoted context omitted.

Buck makes you declare every dependency explicitly. A particular target must specify exactly what files it uses, and when it makes a build, it copies those files from the target and all its dependencies into an empty sandbox and builds there. It's wonderful.

Wonderful until you have a few thousand files you need to declare explicitly. Or do I misunderstand something here?

https://buckbuild.com/function/glob.html
Post reply on HN