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

181–190 of 204 posts

Re: Bazel 1.0

#181

Post by slavik81 »

philwo wrote: post #124
ageofwant wrote: post #68

Earlier quoted context omitted.

Right. Every time I build tensorflow I have to build bazel first, or get the bazel version for the tf version. I have to say, having used a number of Google's tools over the years: basel, coral sdk, maps api and perhaps others, I'm always surprised at how 'how ya doing' the experience is. Don't get me wrong, I appreciate their tools and its openness, but I wish Google spend a bit more time doing software engineering,…

> Every time I build tensorflow I have to build bazel first, or get the bazel version for the tf version. This is fixed now: https://github.com/tensorflow/tensorflow/commit/991aec351b57... If you use Bazelisk ( https://github.com/bazelbuild/bazelisk ), you'll automatically get the matching Bazel version for TensorFlow in the future (and all other projects that have adopted the .bazelversion file).

Awesome. Bazelisk provides exactly the sort of compatibility I was hoping to see.

Though, manually specifying a maximum Bazel version doesn't seem like it should be necessary. The authors of Bazel know what features they have changed since the version specified as the minimum, and Bazel itself knows what features the BUILD file uses. That information together could be used to calculate the maximum version.

Re: Bazel 1.0

#182

Post by scele »

One thing that I like about bazel is the way it integrates test and build actions to the same action graph and behind the same CLI. Tests are then also hermetic and sandboxed, and can be cached (or executed) remotely.

For example, you could configure your CI to push test results to a remote cache, and when developers check out a clean master, ”bazel test //...” against that cache will report all tests as pass without running anything.

Re: Bazel 1.0

#183

Post by panpanna »

nine_k wrote: post #150
panpanna wrote: post #129

Earlier quoted context omitted.

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.

Last week we had a major security vulnerability in Android just because Google can't user the same Linux kernel that everyone else are using.

There exist LTS kernel versions for a reason, you know.

Re: Bazel 1.0

#184

Post by pjmlp »

fnord123 wrote: post #180
pjmlp wrote: post #177

Earlier quoted context omitted.

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 La…

Unless I am missing something, 97ms looks pretty much sub-second to me.

Re: Bazel 1.0

#185

Post by pnako »

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

I think it's THE standard. Almost all teams at Google use it. It's just the few people outside of Google who are still using legacy tools.

Re: Bazel 1.0

#186

Post by taeric »

klodolph wrote: post #164
taeric wrote: post #85

Earlier quoted context omitted.

Not exactly ringing endorsements here. In large, most of the clones you are talking about are because this is a google pushed product. Chromium specifically is because google pushed it in. Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. It is not uncommon for college or earlier users to just use whatever their IDE does for them. Such that, yes,…

If this is because Google is pushing it, two things don’t make sense to me. - Why would you clone an open-source product because Google is pushing it? - Why are some of the clones older than Bazel? Bazel was open-sourced on Sep 8, 2015, going by first tag, and Buck two days later, so Buck must have been in development for a while. Pants was late 2014, and Please was early 2016. > Regarding everyone at google wanting…

I don't even disagree with what you are saying. I just don't know if it is succeeding because of the quality of the solution, or the weight of the author.

My hunch is it is a little of both. Combined with a giant dose of not caring about existing solutions. Which is not to be scoffed at too heavily. Being able to say "I don't care" about existing users is a huge asset that any startup should not discard. One of your biggest assets is the lack of external assets to be liabilities.

Still leaves me sour to see the hubris that there is something intrinsic to this. There likely isn't.

Re: Bazel 1.0

#187

Post by cerberusss »

munificent wrote: post #168
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.

I'm biased because I work at Google on an open source project, but the complaint here seems to be: 1. A corporation spends significant resources developing a project. 2. Then they release to allow the public to use it at zero cost. Often they even invest in supporting that external use. 3. The project provides enough value to so many users (who chose it of their own volition) that it becomes nearly a standard. And th…

I think it's unfair to sketch it as such. Isn't it clear that the parent is unhappy with the side-effects, rather than the project itself?

Re: Bazel 1.0

#188

Post by namibj »

rjsw wrote: post #115
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…

You could try cross-compiling OpenJDK from x86_64 to ARM. This is a lot easier in newer OpenJDK releases than it used to be. Currently doing this for BSD using OpenJDK 11.

If needed, run with qemu userspace emulation.

Re: Bazel 1.0

#189

Post by EdSchouten »

gravypod wrote: post #179

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…

This has improved lately. Rules_docker's image pusher has been replaced with a copy written in Go. This pusher is built using rules_go, so that it does not rely on any host tooling.

Re: Bazel 1.0

#190

Post by jburgess777 »

adgasf wrote: post #140
emelski wrote: post #91

Earlier quoted context omitted.

Electric Make has had sandboxing since 2002, no conversion from your familiar make-based builds to a new shiny build tool required, and it can make on-the-fly corrections to execution order if that sandboxing reveals that incomplete dependency specifications caused something to run in the wrong order (relative to a strictly serial build). "Sandboxing" in a build tool cannot be claimed as Bazel's innovation.

Can you link to the project?

He was probably talking about a product from Electric Cloud:

https://electric-cloud.com/plugins/directory/p/emake/

Post reply on HN