Buck – A build system developed and used by Facebook

I don&#x27;t work in a shop where performance&#x2F;speed is important, but I am looking for other ways to do things I would do in Make but...not in Make.<p>For example, my use-case is similar to what Mike Bostock described in &quot;Why Use Make&quot; [0] when explaining how he uses Make to build out his data tranformation process. Most of my work is data transformation&#x2F;small-scale ETL, but I just haven&#x27;t been able to get into Make beyond trivial work, and I often end up writing things in Rake (Ruby).<p>So I was wondering if other devs had tried using Buck&#x2F;Bazel for everyday hobbies and projects, and whether you stuck with the new tool or went back to Make? The portability of Makefiles isn&#x27;t a high priority for me, and I like experimenting with different systems for my own projects.<p>[0] <a href="https:&#x2F;&#x2F;bost.ocks.org&#x2F;mike&#x2F;make&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bost.ocks.org&#x2F;mike&#x2F;make&#x2F;</a>

Buck has been open source for a while! It&#x27;s especially popular among larger companies who have a ton of mobile developers contributing to their apps, but I&#x27;m not sure if FB has ever publicized who exactly is using Buck. Other companies have been contributing to the Buck ecosystem, too, though, like <a href="https:&#x2F;&#x2F;github.com&#x2F;uber&#x2F;okbuck" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uber&#x2F;okbuck</a>

This looks like a clone of Google&#x27;s Blaze&#x2F;Bazel: <a href="https:&#x2F;&#x2F;bazel.build&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bazel.build&#x2F;</a>

&gt; &quot;Buck is a build system developed and used by Facebook.&quot;<p>I have really, really grown to resent this culture of proud and unabashed cargo-culting that we&#x27;ve arrived at in the open source world. Why is this the first sentence describing a new project? Why do we need a Facebook™-approved build system? Does that somehow make it better than the others? And why does Facebook need their own build system? Was the existing ecosystem technically insufficient for them, or was the issue a legal one?<p>Whenever I make this point in dev circles, someone will reply, &quot;They serve X amount of visitors a day, so they must know something!&quot; Well, they also have a firehose of ad money pointed at them 24&#x2F;7.

Continuing the trend of Facebook creating competing tools more often than persisting with and improving existing ones, which I feel dilutes effort and has fragmented a number of ecosystems.<p>We&#x27;ve got a couple of Facebook fans at work, which has left us with a number of our systems using different tools to accomplish essentially the same tasks, and no strong case on either side for us to standardise on one of them.<p>Maybe I&#x27;m just being bitter because I&#x27;ve had a bad experience, but it&#x27;s been a maintenance nightmare for us in the office.

My name is Michael Bolin and I created Buck.<p>When I started the project, Buck had one specific goal: to make Android builds faster (<a href="https:&#x2F;&#x2F;youtu.be&#x2F;CdNw6mRpsDI" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;CdNw6mRpsDI</a>). At the time, the recommended way of building Android (from Google) was to use Ant. So when someone points to Buck as an example of &quot;creating competing tools more often than persisting with and improving existing ones,&quot; I&#x27;d like to point out that you can&#x27;t fix Ant if these are your issues with Ant:<p>* It is unsound. * Because it is unsound, it is irreparably slow. * It uses XML as a build language.<p>Yes, in July 2012, there were a number build systems on the market (though Bazel was not one of them, but Pants was), and none of them focused on building Android. And even if they did, few (if any) software companies were building an Android app as large as Facebook, so it was unlikely that anyone else was going to design for our scale.<p>It also wasn&#x27;t just about build times, but about how I wanted to see us organize code in our repository. At the time, there was a flat list of folders in the Android repo, each called lib-something. This drives me insane because you inevitably end up with two (or more!) people creating com.facebook.common.StringUtils, each in their own lib-something. (It&#x27;s also annoying to `ls` this &quot;lib-&quot; directory over time.)<p>In contrast, Buck&#x2F;Bazel encourage the use of a unified tree, but still encourage fine-grained modularization (which is key as your build graph gets very large). This has been shown to scale to extremely large monorepos at both Facebook and Google.<p>Finally, by having total control of the build system, we were able to build in all sorts of cool tricks to build Android very fast, both in the large and in the small: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;Y9MfGS3qfoM" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;Y9MfGS3qfoM</a>. I don&#x27;t think there is any other build system we could have decided to work with at the time to achieve these gains.<p>Buck has since evolved to build everything else at Facebook. This is not because the Buck team set out to conquer the world, but because people internally wanted the benefits of Buck for their builds. Building an alternative toolchain to xcodebuild was a mammoth effort (and one for which I take no credit). Having one build language for a heterogeneous collection of programming languages in a monorepo is no small feat.<p>Finally, to the people who believe &quot;The big guys want developers locked into their ecosystems,&quot; I have news for you: the Buck team is not offended if you use Bazel, Gradle, Make, or anything else. Buck is open source because we wanted to share it with the community, not dominate it. Like many of you, people are excited to show their work and learn from others.

Buck is a great tool but doesn&#x27;t work on windows, where bazel is now starting to support. So for crossplatform builds, either GN or bazel.

Wow, so many build systems got mentioned here, when do people have the time to check them all out? I stick with gnu make because that&#x27;s the evil I know, not because its the best tool imaginable...

Or just use Nix as your build system.

Can somebody compare this to Gradle?<p>I mean somebody who has actually used both of them (and not read some versus blog posts).

I would recommend gn and ninja. It&#x27;s the chromium build system. The make file is generated in less than a minute with gn, and ninja does a good job with incremental builds. It&#x27;s also been around for a few years so it&#x27;s been proven.

Is there a watch command to detect file change and kick off the build steps?

Tools like Make are also useful for simple data analysis workflows, and I&#x27;m curious to hear any thoughts from any Buck users as to whether it would be useful in those cases too.

Great! There&#x27;s also a Lua-based build tool.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13867347" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13867347</a>

Just what we need.... another build tool!

I sometimes suspect that the build tool ecosystem would be very different if only Makefiles allowed soft tabs.

Wonder if this can&#x2F;will replace CMake for cross platform builds.

Do such tools have any quality&#x2F;security standard?

Does not support Swift at the moment.

Nice build output. Unless you want to look over it afterwards that is.

Anyone care to compare Buck vs pants vs Bazel&#x2F;Blaze?<p>Or perhaps write out your individual experiences mentioning:<p>1) Team size<p>2) Repo size<p>3) Repo programming language distribution.<p>4) development&#x2F;Testing&#x2F;build&#x2F;publishing strategy<p>5) Of course, the actual experience

So much complexity to put some pictures on a screen and have people click &#x27;like&#x27;.<p>It&#x27;s dizzying.<p>I wonder if build-system complexity is an artifact of reducible complexity in other areas.<p>Perhaps the next time we develop a language, it should comprise of it&#x27;s own build system that doesn&#x27;t require any configuration, or rather minimal. To the point wherein we didn&#x27;t need to think that much beyond the obvious.

How come this tool became no.1 trending on HN?

I agree with the comments in this thread, and I add that Facebook knows fanboys are stupid and there are a lot of them, so they try to take advantage of it.<p>&gt; Buck: A high-performance build tool<p>And in the title you read &quot;a fast build tool&quot;, like yarn, as soon as it was released it was the faster one.<p>F: let&#x27;s use yarn&#x2F;buck G: why? F: cause it is faster G: Did you already tryed it? Did you measured or benchmarked it? F: No, but Facebook claims it is fast, come on!<p>By the way, sometimes yarn does not work and you need to add a file to manage it. Furthermore facebook is using the npm registry, do they pay for it or support it?<p>Other than that, thanks to Facebook to bring awesome tools to the public, like React.