Hacker News Reader

Comment by xvilka | Hacker News Reader

While Bazel design seems not bad, could they have used a build system that doesn't require Java? It's especially important for bootstrapping. CMake requires only C++ at least.

View on HN

In practice, this isn't generally noticeable. Bazel is pretty damn fast, and even ships with its own JVM so installing it is pretty much painless.

I agree on the bootstrapping issues resulting from that, though.

Unfortunately, for us, Java “out of memory” errors are routine, and for even moderately-sized monorepos the RAM requirements can get insane.

Precisely this.

Advocating for Java as a general purpose tool language sort of overlooks the incredibly broad and prevasive installbase of machines more than ten years old, as well as the rapidly growing installbase of ARM SOC machines.

For many, a tool eating up a gigabyte or more of memory is certainly not acceptable.

I'm lost. Can't people build their binaries on a powerful machine instead of an ARM tablet?

Not everyone has a powerful machine to do so with; many folks are still using computers that shipped with WinXP, or even Vista or 98/Me. It's a huge world outside of California.

Personally, my primary home/non-work machines are an RPi4 and a Pinebook Pro.

So Google should ship a potentially inferior tool, slower, because some people run on inappropriate or highly outdated hardware?

Hmm.

No, Bazel just fails to satisfy the very real need of building on less powerful machines because of its technological choice, a need served by other tools competing with it, and therefore is not really a truly general, one size fit all, solution.

The fact that you personally deem the needs of others illegitimate doesn't preclude them from actually existing.

The topic is whether FOSS developers should use Bazel, not whether Bazel is good for Google.

For many it is Bazel that is inferior due to development environment constraints.

And "outdated" is a questionable term: if it satisfies their needs, why upgrade?

Maybe Google should build better tools.

I think you're part of a minority, though.

You're talking about computers from 20, 20+ years ago and about Raspberry Pi.

It's a personal choice.

You can get a good second hand desktop from 2012-2015 for the price of your Raspberry Pi.

Travel to Africa, India and South East Asia some time. The world is a big place outside of California, and the hardware available to many is not what you'll find at a cafe in San Francisco.

I've lived in other less developed countries and it's not like a raspberry Pi is the most people can afford there.

Have you lived in the places you've listed?

The RPi is an example of a growing SOC device market, but I did mention as well the enormous install base of older and under-powered devices in general.

I have family in Colombia.

I don't live in California (nor the US), I've only visited twice or so.

I'm from a place similar to those you're describing.

Few people would get enthusiast gear like Raspberry Pi. What they would get, instead, would be an old x86 PC with pirated Windows. A crummy knock off Chinese laptop or locally assembled PC (so not from the big OEMs).

It seems we agree, then? Those devices you mention would be in the category of older, lower-power machines that I mentioned.

Not quite. Even rather poor people in poor countries can get PCs with decent computing power, as PC performance plateaued circa 2010 and old PCs are really cheap. You don't need to get something 20-25 years old when something 5-10 years old is maybe 20% more expensive and a lot more powerful.

Bazel requires gigabytes of memory; for a 10y old machine that's still going to eat up most of what you've got.

I'm curious what you consider "insane" to be -- and I mean this genuinely. Google has what I think most would consider to be a large monorepo, but also provides developer desktops with ample RAM. I've noticed blaze's startup time, but never really thought about its memory consumption. Where are you running into limits?

Doesn't blaze build remotely via citc? I thought files were loaded locally for editing but built remotely.

Blaze itself runs locally, reading BUILD files from citc. The build actions mostly execute remotely.

10,000+ artifacts on a 20 core Intel box with 64 Gb RAM.

We have some peculiarities of our Bazel setup that are not common, yet are (supposed to be) fully supported.

Building can take hours.

Are you using remote execution with Bazel? If you have hour long builds, it's often worth investing in remote execution (just remote caching can help too).

The effect is that open source projects avoid Bazel. I'd rather fight with CMake than take a Java dependency in a C++ codebase.

It's a pity, feels like a real missed opportunity.

I think open-source projects avoid Bazel not because of the Java issue. You can install it pretty easily and never realize that it's written in Java.

By analogy, I'd say that if Make is a hammer, Bazel is a CNC machine. Most DIYers are going to have hammers, and everyone understands how to use them, but CNC machines are becoming cheaper and more common.

The official .deb is 156MB compressed, which is prohibitive for all but the largest OSS projects. I assume much of that is the bundled JRE, but that only illustrates the point about Java.

Most tellingly, Google has gone through two major build system migrations (Android and Chrome), and neither project chose to migrate to Bazel/Blaze. If Google won't eat their own dogfood, it doesn't inspire much confidence.

> If Google won't eat their own dogfood, it doesn't inspire much confidence.

Chromium's gn started being prototyped in 2013 [1].

Android's soong started being developed in June 2015 [2].

Bazel's first open source release was in September 2015 [3].

In addition, you surely can't be serious about Google not 'dogfooding Blaze' - it's a critical build system internally at Google. And new external projects (like gVisor) are also now built using Bazel.

[1] https://chromium.googlesource.com/chromium/src/tools/gn/+/3b...

[2] https://android.googlesource.com/platform/build/soong/+/e441...

[3] https://github.com/bazelbuild/bazel/releases/tag/0.1.0

In addition, both Android/Chrome need to support Windows as build host, and bazel's Windows support was not added until much later.

> The official .deb is 156MB compressed, which is prohibitive for all but the largest OSS projects.

I'm not sure what to make of this statement. Why is 156MB prohibitive? You don't need to include Bazel in the project any more than you need to include Xcode for the macOS version of a project. You can specify a version of Bazel with .bazelversion so you don't need to worry so much about people using the wrong Bazel.

There are some systems like Waf and Autotools where the build system is customarily bundled inside the source release, but this is not universal--if you use CMake, it's almost certainly not bundled either.

> Most tellingly, Google has gone through two major build system migrations (Android and Chrome), and neither project chose to migrate to Bazel/Blaze. If Google won't eat their own dogfood, it doesn't inspire much confidence.

Android is a fairly large project itself consisting of the Kernel (which has got its own custom build system) and a ton of different components. From what I understand, for NDK projects, Bazel is moving towards "the one sane way to do things", it will just take time, this stuff doesn't happen overnight. For non-NDK (pure Java or Kotlin) projects, there's not really a point.

Chromium is a bit of a special snowflake and predates Bazel's Windows support, and a codebase the size of Chromium would take a long time to migrate--but it looks like it's heading in that direction. From what I can see in the revisions to the Chromium build system, it seems that it's massive custom build system is moving towards Bazel by leaps and bounds. It's already structured like a Bazel project and uses much of the same terminology, I wouldn't be surprised if a few hundred Bazel scripts appear overnight in Chrome, because it looks like much of the groundwork has been done.

Android and Chrome also both use git for version control. Take that how you will, but I don't think it's an indictment of Piper (https://research.google/pubs/pub45424/)

All the official Bazel .deb files since Bazel 1.0 have been around 42MB See https://github.com/bazelbuild/bazel/releases/tag/3.7.0 for the latest release

Most open-sourced Google projects use Bazel now. Of course, projects like Android and Chrome have been around for a long time and have invested in their build systems, so any change will take years.

(disclaimer: I've worked on Bazel)

> I agree on the bootstrapping issues resulting from that, though.

What are these "issues"?

To build Bazel from source in an environment where you don't want to use any Internet binaries, you need a Java built from source. Needing a Java is painful. You also need a Bazel to build Bazel.

And Bazel's build system itself IIRC wants to download stuff from the Internet on build - which can be pre-fetched, but distro maintainers still don't like having to deal with taht.

Edit: never mind, I think I was confused what the comment was saying.

Look at what Nix or Guix would have to do to build a project using Bazel vs a project using CMake.

This is nonsense building OpenJDK from source should be as easy as:

    bash configure && make images

The speed and responsiveness is there, but the price is a tricky management of background daemon and aggressive memory prefetch and caching which may be a bit heavy on memory resources (which is then less available to the compiler processes). This works out well when you run the Bazel daemon locally and distribute the work to a remote build farm, but less when you're building a project like LLVM on your laptop.

As far as implementation languages go, Java is mature, extremely stable, doesn't suffer from the quirks and foibles of older languages like C++, and is slower-moving than some of the newer languages. I know I've complained about running Java services but I think it is a great choice for writing a build system.

Can I shamelessly plug my build system https://please.build? It’s a Bazel-like written in go with a focus on simplicity.

I feel your pain, We had a lot of the same complaints with Bazel, Buck, Pants etc.

If you have the cycles porting the LLVM bazel build system to please and comparing performance and usability would be pretty sweet.

It seems like a great public use case/benchmark for a large common project to test with.

You might like GN, which is Bazel like design but in C++.

Defaults to Ninja and its superfast.

https://github.com/timniederhausen/gn

Does GN do all the deterministic build stuff that Bazel does?

Not as far as I understand. It's closer to CMake/Meson than to Bazel.

But no feature tests IIRC

Reply on news.ycombinator.com