Bazel is a powerful yet complicated system, and it can be intimidating to newcomers.
While the Bazel user guide and user manual preach the benefits of giving Bazel full control over your build process by rewriting all build processes using Bazel-native rulesets (as Google reportedly does internally), this is an immense amount of work. Specifically, if you are integrating third-party software into your Bazel-based build process, reverse engineering and rewriting the third-party project’s build system into Bazel can easily take days – and then you need to maintain it.
Start simple by prioritizing getting a working Bazel-based build system
up and running as quickly as possible. For third-party software that already
has an existing build system, start by using Bazel genrule
s to
call into the third-party system. For code that you write, try the
existing Bazel native rulesets first, but switch to genrule
s if they
don’t meet your needs.
For example, let’s say I want to integrate libpng into my project’s
monorepo. libpng has an autoconf-based build system which would
require substantial engineering effort to replicate. Rather than
spending days rewriting the build system, I’ll start by just calling
into the libpng build process using http_archive
and genrule
,
largely replicating what I would do if I built libpng by hand outside of
Bazel.
|
|
|
|
See https://github.com/sengelha/practical_bazel_examples/tree/master/start_with_genrules for a full, working example.
Over time, as your Bazel experience increases and you identify your build process pain points, you can selectively rewrite your genrules into Bazel-native rules – potentially even creating your own rulesets along the way.