Live data from Hacker News

Bazel 1.0

opensource.googleblog.com

11–20 of 204 posts

Re: Bazel 1.0

#11
post #3

Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?

My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you build all the apps that depend on the proto you updated? Do you need to build your PHP app because you change an internal go library? Tools like "docker build" have no idea and tend to rebuild too much or too little, and yield different results on different machines. This causes a lot of headaches.

The thing that kills me about Bazel is that it is quite painful to deal with Java. I never seem to get a working version on a Linux distribution. On Windows it's always sitting down in the taskbar showing ads. Oracle calls you to demand money. You check the bounds of an array and they sue you. It's just not worth it. So I don't actually use Bazel.

Re: Bazel 1.0

#12

I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.

Why do you care if a JVM is on your dev machine?

Re: Bazel 1.0

#13

Because I have a twisted fascination with controversy and tribalism on HN, here's a little red meat: I'm going to stick with using make to glue together whatever tools I need for my build and test processes. Edit: -5 in under 10m. And yet I didn't even say anything remotely controversial or normative. Fantastic.

For me the obstacle for using make is, it is not available for windows and even if I install via msys2 or cygwin, it is hard it make Makefiles independent of OS.

I am not sure Bazel is the answer. BUILD files feel verbose and need more effort to maintain than platform specific files(go.mod, Cargo.toml, pom.xml).

Re: Bazel 1.0

#14
post #3

Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?

Long-run, yes. Projects are too often multi-language these days, and if you mix C++ and Java, there might not be a clear or convenient seam between the C++ and Java parts.

Short-term, it will take a while after 1.0 for the surrounding tools and libraries to stabilize. It will take a little while for better documentation, blog posts, etc.

Personally, I find it a huge step up from e.g. CMake for C or C++ projects. But I’ve been using it for a while.

Re: Bazel 1.0

#15
post #6

Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.

Bazel's goal wasn't (explicitly) to be simpler or more straightforward (though I'd argue that its restrictions do cause that in many cases). It was built to solve problems that other build systems (make-like) don't: hermeticity and reliability of builds.

Re: Bazel 1.0

#16

I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.

I think you don't need to install Java to use Bazel, it comes bundled. They have done some improvements to installer so that the user requires as less additional tools as possible to run Bazel.

Re: Bazel 1.0

#17
post #3

Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?

My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…

On Linux I just install a headless OpenJDK 1.8. Something similar is available through brew on the Mac.

Oracle’s version is dead as far as I care.

Re: Bazel 1.0

#18
post #9
post #6

Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.

obligatory: https://xkcd.com/927/

That's the one!

Re: Bazel 1.0

#19

I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.

Parts of Bazel are written in C/C++.

The command line client as well as some low level file utilities.

But Bazel is distributed as a standalone package in several packaging systems; no need to install Java yourself.

Though I doubt many people know this; there's virtually no reason you would be exposed to its language implementation choices.

EDIT: Actually I believe Bazel is changing its .deb package to not be standalone, in order to comply with Debian requirements.

Re: Bazel 1.0

#20
post #3

Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?

My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…

I use Amazon Corretto. There are few other openJDK distributions.
Post reply on HN