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

Bazel 1.0

opensource.googleblog.com

Post reply on HN
Print view View original

141–150 of 204 posts

Re: Bazel 1.0

#141

Post by RayDonnelly »

halflings wrote: post #26
taneq wrote: 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 is almost a standard for build systems at this point. Did you ever use it, or at least see what a bazel build rule looks like [1] before calling it arcane? [1] https://docs.bazel.build/versions/1.0.0/tutorial/cpp.html#un...

Bazel is the bane of every software packager who needs to use it and who does not work for Google. GN (or whatever it's actually called) is a close second in terms of horridness and NIH-ness, then GYP (and depot_tools too, may as well chuck that in there). Guess which company foisted all this on us?

Re: Bazel 1.0

#142

Post by Nullabillity »

choppaface wrote: post #89

One of the major time savers of bazel is Remote Build Execution (RBE), which allows you to build modules in parallel in the cloud. So if you have 1000 CPUs, you can really just have a client do `bazel build -j 1000 //...` and you can get a huge speed-up. Remote (and local) builds all happen in a sandbox, so you don't have to worry about e.g. preparing a docker image with the worker / build slave environment. (You do,…

Nix also supports using any SSH server with Nix installed as a remote builder[0]. Performance gains aside, it's also very useful for building for other platforms where you don't have a cross-toolchain set up. For example, I've had some colleagues use nix-docker to build packages for Linux from their Macs, even if the packages weren't cross-aware[1].

[0]: https://nixos.wiki/wiki/Distributed_build

[1]: https://github.com/LnL7/nix-docker#running-as-a-remote-build...

Re: Bazel 1.0

#143

Post by MapleWalnut »

kartayyar wrote: post #127
throwaway1777 wrote: post #59

In my opinion Bazel/Blaze and Buck are mainly useful to solve the problem of having too much code to build on one machine. Reproducible builds which can be done in a distributed fashion aren’t really useful when you can build your whole project in a minute or two on one machine. That being said, once you get the hang of it the overhead is not too high compared to simpler systems.

Xoogler here who used the internal version of Bazel ( blaze ) extensively, liked it and now opted to use it for our 2 person startup ( at least for the backend ). You don't need a giant codebase to start benefitting from it. Even if you have a smaller codebase, and properly use bazel to setup tests, you only test what needs testing, and that makes a huge difference in productivity.

What languages are you using with Bazel? I have a project that uses Typescript and Python. Are you using Bazel with interpreted languages?

Re: Bazel 1.0

#144

Post by cma »

cromwellian wrote: post #131
jhasse wrote: post #120

Earlier quoted context omitted.

> python and node build systems have even worse startup times and no one says anything. Noop build with Waf (build system written in Python) takes 0.13s on my system. Waf reports that the build actually takes 0.04s, so I guess 0.09s is Python's start-up time (and some other overhead).

Java Hello World takes 0.132s on my Macbook pro. If I turn on -Xshare:on to use class data sharing, then it drops to 0.119s. Ergo, Java startup time is non-factor. Graal could make this even quicker, for example, a GraalVM AOT helloworld can be reduced to .008s startup, see https://github.com/graalvm/graalvm-demos/tree/master/java-ko... for example. "time bazel" returns 0.098s Running a null build took 0.84s, but Baz…

> "time bazel" returns 0.098s

For me it returns 1.6s on first run, .9s on second (bazel 0.29.1).

Re: Bazel 1.0

#145

Post by hanwenn »

willtim wrote: post #119
laurentlb wrote: post #100

Earlier quoted context omitted.

No. I work on Blaze/Bazel. The vast majority of the code is shared between Blaze and Bazel. Examples of Bazel-specific code include support for Windows and support for external deps (needed for multirepos and interaction with package managers). The core is exactly the same.

My employer encountered lots of basic bugs, like file handle exhaustion, which together with the amount of recent activity in GitHub, suggested to me that there is a lot of new code in Bazel. If it's essentially the same as Blaze as you say, then why the new name?

I was there when the name was selected. It turns out "blaze" suggests speed, which is why it was a popular name for other software, and some of it was registered as trademark.

Re: Bazel 1.0

#146

Post by journalctl »

blub wrote: post #81
arianvanp wrote: post #79

Earlier quoted context omitted.

We didn't have Bazel on ARM for NixOS because we can't bootstrap openJDK on ARM. There's no source code for a JVM that compiles on ARM afaik. Though in theory we could package binary blobs from oracle and bootstrap JDK and Bazel from there, it means now our trust path for your critical build tool has a random Oracle blob in its trust path there that is extremely hard to get rid off. Build systems should be easy to bu…

Google builds stuff for themselves and then dumps it for extra reputation points on the dev community. The part where this starts to suck is when their tools become pseudo-standards and everyone has to live with their decisions.

They even maintain internal tools that are similar versions, but better. Google uses Borg internally, but they open sourced the cheap knock-off known as Kubernetes instead.

Re: Bazel 1.0

#147

Post by human_error »

How is it different than Buck or Pants? What makes Bazel better than them? If I already use Buck or Pants what benefit would I get if I move to Bazel?

Re: Bazel 1.0

#148

Post by frankgrimes97 »

imrehg wrote: post #93
pgrulich wrote: post #84

Earlier quoted context omitted.

Is not the openjdk available for arm? What do you need from Oracle? https://adoptopenjdk.net/releases.html#aarch64_linux

This is aarch64 (that is 64-bit ARM), and NixOS seems more 32-bit arm looking at their wiki https://nixos.wiki/wiki/NixOS_on_ARM On the other hand, they do 64-bit too, so maybe there would be some way to do for one, then bootstrap the other? Other idea, distributions like Debian, seems to build OpenJDK as well, so maybe that would be a way to get the initial package (through an existing distro) https://buildd.debian.…

Aren't there 32-bit ARM binaries available here? https://bell-sw.com or here? https://adoptopenjdk.net/releases.html?variant=openjdk11&jvm...

Re: Bazel 1.0

#150

Post by nine_k »

panpanna wrote: post #129
blub wrote: post #81

Earlier quoted context omitted.

Google builds stuff for themselves and then dumps it for extra reputation points on the dev community. The part where this starts to suck is when their tools become pseudo-standards and everyone has to live with their decisions.

This is actually called the "throw over the fence" open source development model. Most Google projects are like this, including Android which is the main reason why vendors struggle with os updates.

AFAICT Android is a pain to upgrade because of custom closed-source drivers and lack of ABI stability in Linux, so you need to recompile a driver for a newer kernel.

Android is not a Google's internal product, unlike Bazel.

Post reply on HN