2 ms·
Build rules for bazel are straightforward when you’re on the happy path & trying to do something that bazel already understands. It’s when you’re not on the hap
by pja 7y ago
Build rules for bazel are straightforward when you’re on the happy path & trying to do something that bazel already understands. It’s when you’re not on the happy path that things get awkward.
E.g. How easy is it to integrate a new C++ compiler into bazel? (and I don’t just mean what you get by changing CC to point somewhere else. I want the full integration with the bazel build system in order to get those hermetic builds that are the whole point of using bazel in the first place).
How easy is it to build things which are not in the set of blessed languages? What if I have a Haskell component? Can I easily integrate that into my bazel build? Last time I tried the answer was definitely not.
If you can use the pre-defined BUILD rules then bazel is pretty great. If you can’t and have to start wading into the weeds of bazel’s hinterland then it rapidly stops being so. If you’re inside Google, then you’re probably fine because a blaze/bazel engineer is ultimately only an email away. For the rest of us outside the Googleplex, extending bazel is an extended exercise in frustration in my experience.
- ondrasej 7y agoThere's genrule() which basically runs a shell script. With that, you can build anything for which you can write a command-line. And you can go as far as invoke a binary that is built by another bazel rule. You can also define your own rules in a subset of Python (by wrapping other rules including genrule()), so adding new languages should be simple enough.
- pja 7y agoBased on my experience with bazel the phrase “should be simple enough” is doing an awful lot of work in that sentence ;) It’s just a SMOP, right?