search

LoopPerfect / buckaroo

The decentralized package manager for C++ and friends 🏝️
https://buckaroo.pm
MIT License
933 stars 33 forks source link

What are the future plans around Bazel? #367

Open cpsauer opened 4 years ago

cpsauer commented 4 years ago

Hey @njlr,

We've been using buckaroo and BUCK for a long time, but we're considering a switch to Bazel. I see a bunch of commits recently from you around Bazel support for buckaroo. Could I ask what you all are planning there? Is the plan to wrap repos that build with Bazel? Or to switch over to support bazel entirely? (Or something else?)

Thanks so much, Chris

njlr commented 4 years ago

Hi Chris,

Sorry for the delay!

So as you are no doubt aware, Buck and Bazel are very similar. Both are inspired by an earlier internal Google build tool; I think it was called Blaze. Due to its use in Tensorflow, Abseil and other open-source Google projects, it seems that Bazel is becoming the most popular build-system in this family; others include Pants (Twitter), Brazil (Amazon internal) and Please (ThoughtMachine).

Our plan is to support Buck and Bazel, but migrate to Bazel as the preferred option. This means adding some code to Buckaroo (as you have noticed) and also migrating the packages we provide to contain both BUILD.bazel files and BUCK files.

Aside from the cosmetic differences (e.g. cc_library vs cxx_library) Bazel and Buck take quite different approaches to genrules and headers. In Bazel, all files in the sources list and outputs are paths relative to the workspace root. In Buck, they are relative to the rule's output directory. The Buck system is more powerful and Bazel's is closer to how in-source build-systems work. In any case, this makes the porting process hard to automate.

Bazel also has the ability to fetch remote workspaces as part of a pre-build step. This has some overlap with the functionality of Buckaroo, although it is not as powerful. In Bazel, only the top-level WORKSPACE file is considered so transitive dependencies are not handled for you. The idea is that in Bazel mode Buckaroo will automatically generate a macro that builds your WORKSPACE automatically. We have already sketched an implementation of this in the latest version of Buckaroo.

In the future, we will add further package sources such as NPM and Maven to the existing ones (Git, HTTPS, GitHub, etc.) to enable Buckaroo to support mainstream languages. Since Bazel can build these languages we will have a pretty compelling combo for polyglot projects!

Hope that helps, let me know if you have any questions.

cpsauer commented 4 years ago

Thanks for replying so fast, @njlr! Definitely no need for apologies :)

Sounds like we should plan on migrating to Bazel with you guys. We're a polyglot project if there ever were one--and I'm actually most familiar with Blaze, after some time within Google. Separately, quick pitch for wrapping CocoaPods, given all the iOS/mobile use of these build systems.

Any sense for the timeline, so we can sync with you all? And is the plan to defer problems with the current version (e.g. #363, #364) until Bazel support is complete?

Thanks so much, Chris

nikhedonia commented 4 years ago

Roadmap will be determined mid February and active development will start end of February. As @njlr mentioned our goal for this year is to make Buckaroo more suitable for polyglot projects and we will try to integrate as good as possible with other established (bazel, npm, maven, etc...) ecosystems while maintaining our initial design goals