[entelechy]

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.

[Game_Ender]

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

[entelechy]

> 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

[hlopko]

I'd say the main the challenge that both Bazel and Buck have to face in the C++ land is that it's still too much work to migrate an existing cmake/autotools project to them. One nice project that tries to tackle that is https://github.com/bazelbuild/rules_foreign_cc. But yes, there are minor things that make migration from Bazel to Buck or vice versa not as smooth as it could be, and I'm confident those will be fixed.

To me the biggest added value of Bazel is the remote (build and test) execution (which will get a nice performance boost from https://github.com/bazelbuild/bazel/issues/6862 in Bazel 0.25; also mentioned in [3]).

(Your [3] doesn't compare Bazel and Buck, only Bazel with remote caching and without it, so it's not clear from it that Buck leverages caches better than Bazel).

And one nit, Bazel doesn't allow you to download anything in the loading, analysis, or execution phases ("the BUILD files"), those are completely hermetic, sandboxed, and reproducible (when compilers are). The package manager integrations happen when resolving external repositories ("the WORKSPACE file"), where non-hermetic behavior is allowed and is used e.g. to autoconfigure C++ toolchain, or download npm packages.