Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bazel 2.0

blog.bazel.build

Post reply on HN
Print view View original

111–117 of 117 posts

Re: Bazel 2.0

#111

Post by bobdobbs666 »

klodolph wrote: post #101
bobdobbs666 wrote: post #69

I was subjected to bazel on a small project because the manager insisted we use it. The rest of the company used a number of either custom tools or cmake or premske. It is utter hell when you have tons of third party libraries (internal or external to the company) that you don’t have the source to and it is especially painful when trying to integrate bazels behavior against other build systems. Also bazels packaging…

My personal experience is that Bazel cut through a bunch of the problems that I’ve had with CMake, Waf/SCons, etc. Builds were fragile, they were not reproducible, and there were implicit dependencies. This is mostly as someone who’s rewritten a few build systems, rather than as someone who’s been subjected to build systems by others (I mostly inflict these changes on other people). With Bazel, I have much higher con…

Lack of docs plus lack of user base is also a giant failing of bazel. It’s almost always impossible to figure out something I could make happen 6 ways with most other build systems make work in bazel. And there’s little community so now instead of getting work done I am debugging bazel source.

Also building distributable packages with bazel never seemed to work well due to the constant aliasing of so files. Things that would work in the direct bazel build would fail in packages and vice versa so now we had even more pain.

Trying to suck up just header files and multiple so files was always arcane bullshit as well.

We did work with git and other such functionality, but if you had to build a package from another build system to bring into bazel there were always annoying pain points.

Also bazel managed to bring in implicit dependencies in our system so that clearly isn’t something bazel magically handles but was rather a product of your expertise.

After reading build systems ala carte I am just more convinced bazel is not the build system that I would really ever need. I’m not sure that build system exists yet to be honest :). But in the work I do other systems solve my problems better.

Re: Bazel 2.0

#112

Post by weberc2 »

joshuamorton wrote: post #108
weberc2 wrote: post #105

Earlier quoted context omitted.

Last I checked (maybe 6 months ago), it definitely _didn't_ support py3, although it was advertised. I thought I was doing something wrong, but there were half a dozen issues in the tracker that indicated it was critically broken. I understand that "it should be simpler" is a pretty lazy criticism. It's been a while since I audited Bazel and friends, and I've forgotten which issues apply to which tool. Moreover, beca…

As of April of this year, python3 was the default for python rules in bazel.

Good to know. Hopefully it works now.

Re: Bazel 2.0

#113

Post by steeve »

jacquesm wrote: post #110
steeve wrote: post #102

Earlier quoted context omitted.

It is true that you rarely start with a new build system. Bazel is hard in the same way Rust is hard. If you port your existing project to it, chances are you will run into issues because you were doing things wrong with respect to hermeticity or reproducibility. It goes really far to make things correct. You may not need it, but when you do it’s a godsend. Or at least it was for a lot of people I talked to. And my o…

I just don't see a new company starting up that one day will need Bazel doing that with Bazel. There is just too much overhead, you won't ever become that company that needs Bazel if you start out that way.

That is a bold statement.

This is not only related to the size of the company but rather the size of the project. For instance if the project requires polyglot build or codegen (gRPC does both for instance), Bazel will shine and save a lot of time and headaches.

That’s not to say that it’s without its problems and that some use cases are very rough around the edges. Which is something the team and community are working to fix.

Re: Bazel 2.0

#114

Post by vlovich123 »

joshuamorton wrote: post #97
vlovich123 wrote: post #95

Earlier quoted context omitted.

What I was saying is that Google somehow manages to track test dependencies at the source level so globbing wouldn't matter.

Frankly you heard wrong. There isn't anything like this.

Yeah, I was misremembering the post from ~8 years ago. I was thinking of this https://testing.googleblog.com/2011/06/testing-at-speed-and-... and it sounds like they do just use Blaze to keep track of explicitly expressed dependencies.

Re: Bazel 2.0

#115

Post by laurentlb »

zapita wrote: post #106
klodolph wrote: post #104

Earlier quoted context omitted.

Go support is awesome, IMO. Personally I have favored Bazel over “go build” for a while, except for pure Go projects with no generated sources. Gazelle is wonderful and it doesn’t belong in Bazel core. Bazel is a build system for every language, and Gazelle is for a subset of Go developers. Since it’s not part of Bazel core, you can always replace it with something else.

But would you recommend using Bazel and Go without Gazelle or an equivalent third party?

Gazelle is a recommended tool, developed by the same people who make the Go rules. It's not a third party tool, it's part of the normal experience.

Re: Bazel 2.0

#116

Post by lima »

thundergolfer wrote: post #103
wereHamster wrote: post #86

Earlier quoted context omitted.

Another factor: are your languages supported by bazel? If you use the same languages that google uses (C++, Python, go), it's fair to say that those are well supported. For all other languages, even if they are widely used outside of Google (JavaScript, nodejs), you may be out of luck.

Python is not well supported. The official rules_python has an inadequate third-party packaging solution that has led to ~5 open source alternatives existing that each fix a subset of the issues in the official. Given that the Python community is really oriented around the PyPi registry and pip packaging tool having a good Bazel-native packaging solution is near essential, but right now it’s not quite there.

Yeah, what's missing is first-party integration with the package manager (like Gazelle for Go) with proper dependency locking.

Re: Bazel 2.0

#117

Post by klodolph »

zapita wrote: post #106
klodolph wrote: post #104

Earlier quoted context omitted.

Go support is awesome, IMO. Personally I have favored Bazel over “go build” for a while, except for pure Go projects with no generated sources. Gazelle is wonderful and it doesn’t belong in Bazel core. Bazel is a build system for every language, and Gazelle is for a subset of Go developers. Since it’s not part of Bazel core, you can always replace it with something else.

But would you recommend using Bazel and Go without Gazelle or an equivalent third party?

I recommend Gazelle for importing third-party Go dependencies but not for your own Go code. If you are using Bazel, just write the BUILD.bazel file yourself with the appropriate go_library / go_binary / go_test rules.
Post reply on HN