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

171–180 of 204 posts

Re: Bazel 1.0

#171

Post by ahupp »

I used buck at Facebook quite a bit, and it's my favorite build system. I assume most of the stuff I liked about buck translates to bazel:

* Build rules were extremely simple to write

* Sandboxing meant we could safely share a global cache of build artifacts, massively reducing build times

* It runs a persistent server process that caches dependency and file change state, so incremental builds are fast

* Buck had a lot of android-specific magic to make APK generation fast as well, not sure if that's in bazel.

A lot of the stuff that's nice about these build systems only really becomes an issue on large codebases (thousands of engineers, tens of millions of LOC).

The main weakness of buck (not sure about bazel) was handling 3rd party code; either you'd checkin prebuilts or port the build to buck.

Re: Bazel 1.0

#172

Post by paulddraper »

cma wrote: post #144
cromwellian wrote: post #131

Earlier quoted context omitted.

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).

Huh; I see < 0.15s.

Re: Bazel 1.0

#173

Post by fooker »

jacquesm wrote: post #99
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…

Isn't there a way to get the Android toolchain to give you what you need? After all Dalvik is just Java warmed over and has a working VM, and there are plenty of ARM based Android phones. That might get you bootstrapped to the point where you can use that to re-compile the community edition of Java.

You are conflating the runtime environment with the development framework. Afaik, you can't develop native Android apps on Android.

Re: Bazel 1.0

#174

Post by paulddraper »

Liquid_Fire wrote: post #125
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).

> so I guess 0.09s is Python's start-up time (and some other overhead) That is probably mostly Waf startup time. Python itself starts way faster than that (on the order of 10-20ms on my machine).

Startup time in any interpreted language is very quickly simply proportional to the amount of code loaded.

   time python -c ''                               # 0.024s
   time python -c 'import argparse'                # 0.036s
   time python -c 'import argparse, json'          # 0.040s
   time python -c 'import argparse, json, httplib' # 0.065s

Re: Bazel 1.0

#175

Post by paulddraper »

fnord123 wrote: post #108
sz4kerto wrote: post #82

Earlier quoted context omitted.

JVM startup is sub-second. Still not great for e.g. small command line utilities, but completely fine otherwise.

JVM startup for `java -version` is around 150ms on my machine: $ time java -version openjdk version "11.0.1" 2018-10-16 OpenJDK Runtime Environment 18.9 (build 11.0.1+13) OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode) real 0m0.159s user 0m0.116s sys 0m0.052s This is how long it takes for a program like git to do actual work. Once you start running an actual program like Maven, it blows up to 500ms for `m…

> make takes under 30ms to do nothing:

But in large code bases, make can take several seconds to do nothing, depending on the number of `$(shell find)`.

Whereas Bazel's time remains constant. Could it have been constantly 30ms instead of 150ms?

Sure. But that's nowhere near to being a problem for the usual code bases Bazel operates on.

Re: Bazel 1.0

#176

Post by paulddraper »

arianvanp wrote: post #79
RcouF1uZ4gsC wrote: post #8

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.

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…

> we can't bootstrap openJDK on ARM

Irrespective of Bazel, that's an lot of software than can't run on NixOS ARM, including build-related stuff:

* Elasticsearch, Cassandra

* Eclipse, IntelliJ, Netbeans

* Jenkins

* Java toolchain, Android toolchain

> (ironic given it being advertised as a cross platform language

Indeed that is one of Java's hallmark features. Servers, desktops, phones, toasters.

---

FWIW it's not unheard of to require compiling on one platform for another. This is how most of the embedded world works.

Re: Bazel 1.0

#177

Post by pjmlp »

lultimouomo wrote: post #155
pjmlp wrote: post #135

Earlier quoted context omitted.

Java 13 takes 97ms on Windows 10, and I haven't bothered to produce a Java native image before attempting it. PS C:\Workdir> Measure-Command { java -version } openjdk version "13" 2019-09-17 OpenJDK Runtime Environment (build 13+33) OpenJDK 64-Bit Server VM (build 13+33, mixed mode, sharing) Days : 0 Hours : 0 Minutes : 0 Seconds : 0 Milliseconds : 97 Ticks : 975572 TotalDays : 1.12913425925926E-06 TotalHours : 2.709…

FWIW, I don't think "java -version" is a good benchmark of java startup time - why should it start up the JVM just to print the version?

I think that measuring anything less than 1s for CLI is silly, school playground measuring competition.

Re: Bazel 1.0

#178

Post by jvolkman »

shantly wrote: post #163
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,…

Used to be able to do something similar with Gentoo back in, like, 2002, I think. Distribute build jobs to multiple remote machines.

https://github.com/icecc/icecream

Re: Bazel 1.0

#179

Post by gravypod »

Bazel, the tool, is fantastic. Haven't had a better build tool that I've seen yet. The build rules are awful. Almost every single rule is broken in some catastrophic way and, as is typical with Google open source, it is very difficult to ask for things to either be fixed or designed differently.

Major examples: rules_python flat out does not work for python 3, rules_docker does not work without python 2, rules_proto cannot generate stubs for languages, you cannot specify third party deps at a package level and there is no explanation as to why (they will say it would destroy hermetic builds or reproducable builds but that doesn't make sense when you think about ways to support both).

Re: Bazel 1.0

#180

Post by fnord123 »

pjmlp wrote: post #177
lultimouomo wrote: post #155

Earlier quoted context omitted.

FWIW, I don't think "java -version" is a good benchmark of java startup time - why should it start up the JVM just to print the version?

I think that measuring anything less than 1s for CLI is silly, school playground measuring competition.

The original comment was "JVM startup is sub-second. Still not great for e.g. small command line utilities, but completely fine otherwise."

For tooling it matters. Some scripts will have backticks and $() and each use of these could be up to a second and be acceptable? Not really. And if you want to run a command like `go fmt` every time you save a file in $EDITOR then you want it to be fast. Maybe when we use the Language Server Protocol everywhere, it will be a different world. But a lot of editors shell out for these features still - and you would never dream of shelling out to e.g. `mvn dependency:tree` because it's too slow.

Post reply on HN